Safe4RAIL-2 (3) H2020 Project: Focus on Work Package 2

Published May 3, 2021, 12:42 PM

In this episode we speak with Jérôme Härri from the Safe4RAIL-2 project. He leads the part of the project which focuses on introducing wireless to replace a network of wires to and from the TCMS, or brain of the train. Quite a bit of research and testing had to be done to reach a point where technologies could be deployed in a demonstrator. 

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No. 826073. The information and views set out in this document are those of the author(s) and do not necessarily reflect the official opinion of Shift2Rail Joint Undertaking. The JU does not guarantee the accuracy of the data included in this article. Neither the JU nor any person acting on the JU’s behalf may be held responsible for the use which may be made of the information contained therein.

Powerful collaborations, cutting edge science and curious minds coming together for a glimpse of the future. Stay tuned as we look at the latest updates on some of the most promising technology projects.

Hello and welcome, I'm your host, Peter Balint from Technikon. Today, we continue our series in the Safe4RAIL-2 Project, where we discuss different work packages to get a better understanding of how they affect the whole. Safe4RAIL-2 is a European project aimed at improving the safety and efficiency of the European railway system. Today, we focus on work package two, which addresses the TCMS, or the brain of the train. As you can imagine, this system is interconnected with wires... lots of wires. In work package two, project partners are exploring the next logical step for the TCMS... wireless. One of the core activities of this work package was the development of equipment suitable for the wireless train backbone. Here to tell us more is Jérôme Härri. He is an associate professor with the Communication System Department at EUROCOM, and he has done considerable research in the field of wireless vehicular communication. In Safe4RAIL-2, he's the leader of work package two. Welcome, Jérôme, and thanks for coming on today.

My pleasure.

We will talk about your specific contributions to Safe4RAIL-2 in a moment, but a common question when people hear about projects like Safe4RAIL-2 is when could we expect to see these changes and improvements in trains? And I see their point. I mean, technology wise, you are well developed, but interestingly, when we talked offline, you mentioned that it's not just about the technology, there are other considerations like certification and regulation and these kinds of things. What could you tell us about this?

Exactly. So from technology wise, I mean, the using the cellular technology LTE-V2X to provide the wireless train backbone, it's something that's existing technology. The LTE-V2X is ready since 2016. So it could already be included in theory, already in trains. But what is the complexity is it's in a different place. The first is obviously the certification/ regulations. So for certification, the challenge is to be able to certify that the technology behaves according to what is specified in the standards and the regulations is basically to define the standards that that the devices have to follow. And one of the... I would say long challenge challenging issue is specifically in the regulations in, for example, the spectrum access. The LTE-V2X technology has been specified to use one spectrum bands in 5.9 GHz. Unfortunately, the regulations limit it for the automotive industry and urban rail, but not traditional rail. So then the stakeholders have to discuss to find the correct spectrum. And that is very difficult to find because spectrum is not available everywhere and that is has to be agreed on a European wide level. So that's that's complex. A second challenge is security. Security, when we talk about a train talking to another train, people see that as a giant loophole for potential cybersecurity attacks. So even if the technology is ready, we have to provide security mechanisms to keep it safe and to keep it cybersecured. And that is taking a lot, lot of time. And finally, what is also complex is to integrate that that system within all other systems that it can integrate correctly and play its role as part of a larger... a larger interconnected system. And that is what is really taking time. And I can give an example in the fact that within the automotive industry, the LTV 2x is ready in 2016, but we still do not see in commercial business currently in commercial cars, we do not see a LTE-V2X technology being widely deployed, even though that the hardware exists. And even worse, if we look at the competitor, the Wi-Fi technologies, something called in Europe ITS-G5 is ready since 2008. And still we don't see that in the vehicles. So we see that technology is not really... it's complex to develop, but it's at the end, never the blocking factor.

Wow, so it looks like in cases like this, the regulation and the paperwork is the real bottleneck, not necessarily the technology.

Exactly. And the bottleneck is always because it's also because it's very difficult to make people understand each other. If you develop in parallel the technologies and the regulations, then sometimes it's people from different backgrounds, the engineers developing something. Usually they want to develop the perfect protocol. But then something that I always teach in my in my class is to say that you can you cannot standardize a protocol that cannot be certified. And certification is something that has to be deterministic and means that it has to be simple enough to have a single input and to have a deterministic output. That is something that automatically limits the innovation that you can get in a system. And then you have always this... I would say, discussions and interactions between the engineers and the certification engineers by developing an algorithm that is efficient and developing an algorithm that is certifiable. And at the end of the day, sometimes you end up having something too simplistic to have because it it has to be certified is certifiable. And the fact that these two communities have different objectives is one of the reason... it's also limits the the developments. At the end, the paperwork cannot be done at the same time as at the development of the technology.

So bottom line, I guess once you've developed something technologically doesn't mean you can let it fly. There's a process that has to take place.

Yeah, I mean, if you were in the perfect world, I would say we should develop that in parallel. And I'm pretty sure that if there was sufficient pressure, people could do that. But we at the end, we are all researchers and we do... we work on the best effort basis and it's very difficult to have these two operation being developed at the same time. And therefore, yes, you develop a technology, it's ready to be deployed, and then we still have to to operate it. And one typical example is the LTE-V2X technology ready in 2016. But it couldn't be operating in Europe because he was not told it was not included into the ETSI architecture. And if it's not included into ETSI architecture, then it cannot be allowed in the European Union. And it took it took two to four years to and to include the LTE technology into the set of standards that needs to be changed to enable the LTE-V2X technology.

So let's move on to your part in Safe4RAIL-2 which is work package, two. If we look at the website, it says that work package, two is focusing on developing a wireless communications for the TCMS. Is this with LTE or 5G or both?

But that's a very good question. So when the call, I mean, the project answered to a specific Shift2Rail call and at that time, the only technology that was available or foreseen was LTE-V2X technology. So that's why it was indicated as LTE-V2X . And the second reason was also because at that time the LTE-V2X technology was the only technology with a forseen developments of product. So the idea was to say it was developed for vehicles and so why not using it for trains? And that's that was the state of mind. But once we developed, we started the project, then we... at the same time the the 3GPP extended and started to move and work on 5G. Then we we started to realize that's we started to ask a question of whether 5G could be better. And during the project we evaluated if the LTE-V2X technology was capable of supporting the requirements of the wireless TCMS and we realized it was not. But the good news was that the five 5G-V2X proposed some key innovations that would actually fulfill the requirement of the of the wireless TCMS. So it doesn't mean that Safe4RAIL-2 will give up on LTE and directly to 5G because the 5G, if it works, is not ready yet. The standard... the specification is completed, but there is no product yet. But it just shows that basically we are in the wrong time in the sense that the project came a bit too late for the LTE-V2X and a bit too early for the 5G-V2X . So within Safe4RAIL-2 what we decided to develop a prototype based on LTE-V2X and show that it is doable that we can do things we can provide wireless TCMS based on their LTE-V2X , but also identify the key innovations that are required for 5G-V2X and provide guidelines for what needs to be done once we have to be V2X, the 5G-V2X ready.

Yeah, excellent solution for this problem of being caught in the middle. I would say. So your work package is also charged with identifying issues with wireless TCMS . Were there any unexpected results in your analysis?

So, I mean, we saw a lot of different issues and was related to the limitations that I mentioned with the LTE-V2X, we realized that basically LTE-V2X was not meant to be used for the wireless TCMS for multiple reasons. One of them was that what was what was expected from the wireless TCMS was not supported basically by the LTE-V2X standards. So it was... we need to change the standard and that was not possible, considering the fact that we were moving to 5G. Another aspect that we also discovered is the performance aspect, of course; so it was already known that the LTE-V2X had some limitations in the performance for automotive communication, which is more or less the same limitation that you have it also with the WiFi competitor, but with the wireless TCMS what we have to provide is industrial wireless quality and reliability. So at the end, what we expect is a very high level of reliability. And as I was mentioning before, deterministic communications and the LTE-V2X doesn't support deterministic communications. So that was first a limitation. We couldn't provide the level, the level of the expected level of delay or reliability that was expected by the wireless TCMS. So the idea of having a wireless link that is transparent to the Internet train backbone was basically not possible. The network will automatically see that there was a weak link. And that is wireless link, the second aspect we also discovered we also saw was the which is which is the basic wireless aspect to the range to the how far we can we can communicate. Obviously, we need to if we want to have a high reliability and communication, we need to reduce the communication range. But by doing so, we need to rely on multi hop or mesh architecture, which is again, not supported by LTE-V2X technology as well. So at the end, we saw that even though that's from a pure hardware perspective, the LTE-V2X technology is capable of providing a direct one device to device communication that we can do between consists, which is great. But there is a significant additional requirements that were not designed for the LTE-V2X , it was targeted for the automotive industry and that was the limitation for the wireless TCMS.

Yeah, now, also, your work package involves developing a prototype. Can you tell us about it? What was it? And is it still under development or is it been tested as of yet?

So, yeah, so basically we developed a wireless backbone radio device prototype based on the LTE-V2X technology and that we developed it with the open interface software defined radio platform. And as any prototype, it's always being, it's always on current developments so it's never finished. So we yes, we are still developing it. So, um, the platform to open interface is a software defined radio platform where all the codes are in software. We just have a radio front end with with minor hardware requirements. And so as we develop everything software, then we have also access to the source, as I was mentioning, is also open source. And we can develop the protocols and we can even, that's the good side of it, we can even change the protocols even if they are not the ones that are part of the standard. And that's basically how we manage to correct some of the missing... the missing functionalities that we identified by the for the wireless systems that we could change and and enhance for Safe4RAIL-2. And maybe I can conclude with open interface, open interface, what we developed, it was just the side that the LTE-V2X side but open interface is a very large platform with a community platform, with a lot of stakeholders that are interested in open source development. So the platform has open source code for 4G and 5G technologies and being developed... it has been funded by your Eurocom, but has been now developed by a large amount of potential stakeholders.

Yeah, and the way you explain this, it makes complete sense. And it sounds as if we will gradually be seeing more and more open source components in our infrastructure and transportation. And finally, it's always interesting to hear about some of the setbacks that a project may experience or maybe a little bit of derailment along the line or lessons learned. Did you experience anything like this? And if you did, then how did you work around these issues?

The first challenge was to provide a service on a system that was not designed to provide the quality required by that service. I think that's the biggest challenge. It's basically if you want to transmit video streaming over a Aloha wireless protocol, I mean, to be a bit extreme in the comparison. So you need to be you need to find mechanisms to be able to to to still make it work, even though that the system itself doesn't support the level of the level of service. So typically, we had to improve the... we need to design new ways of accessing the channel to provide the level of requirements that the system expects. So I think that was one one typical aspect. The second is obviously also the fact that it would have been also nice to be able to have the hardwares already available . Even though that we we developed open source softwares and prototypes, it would have been also nice to be able to have a product that we can compare interface with to see if the system works. But so far, we only make two prototypes, interact between each others so that we still have this interoperability interoperability test that we need to do. But this is something that we are going to do in Safe4RAIL-3 . But maybe another bigger thing was the intagration. We in Eurocom we developed the wireless backbone radio device and it has to be integrated within the Ethernet train backbone and within train consist, which are both of them, something that you cannot displace, you cannot move. So the project initially was designed just that we had some integration camps. We have to to to travel together and join and integrate our systems in a lab or close to a train. I mean, maybe not directly on the train, but at least with the hardware used by the train. But the COVID made that life very difficult. And at the end, we had to develop mechanisms to do interoperability tests between the systems that are within a train and our wireless systems remotely. And that was not that was not designed as such in doing the project. But at the end, what was interesting, because the mechanism we developed within Safe4RAIL-2 will actually be used beyond Safe4RAIL-2 in the sense that we developed a mechanism to do remote interoperability tests that we will use in Safe4RAIL-3 and even with other European project that had the same issue with the COVID situation.

And that's a great example of taking a challenge and turning it into something that everyone can benefit from in the future.

So, I mean, that's there's always I mean, we have to have some good things out of this. And we basically developed new solutions and we hope that we can keep on using them. It was actually... we discovered afterwards that it was even a solution to solve intellectual property aspect, not specifically in Safe4RAIL-2 but in other projects some partners wanted to test some systems, and they did want to release what it was, and the system that we developed with Safe4RAIL-2 was judged as a potential solution for avoiding that's the partners for for letting the partners test the system without basically having to share the system with other potential competitors.

Wow. Hats off to you and your team for that accomplishment. Thanks so much for giving us some insight into your work in the Safe4RAIL-2 project you have presented some really helpful information today.

Well, thank you for the interest in our work. And I would like to conclude by the fact that this wireless train backbone, wireless TCMS and wireless backbone consist network, it was a corporation with a lot of partners. I didn't mention it explicitly before, but it was a corporation with all the different partners of work package two and success that we had is also to be shared with them.

It's nice of you to point that out. Thanks again.

Thank you.

This podcast has been brought to you by Technikon. This project has received funding from the European Union's Horizon 2020 Research and Innovation Programme under grant agreement number 826073. The information and views set out in this program are those of the authors and do not necessarily reflect the official opinion of the Shift2Rail Joint Undertaking. The joint undertaking does not guarantee the accuracy of the data included in this episode. Neither the joint undertaking nor any person acting on the joint undertakings behalf may be held responsible for the use which may be made of the information contained herein.