#108 — CBTC Interoperability: Why It's Harder Than You Think, with Dr Alan Rumsey

CBTC has been the world's de facto metro signalling standard for 40 years. In all that time it has never been made interoperable across suppliers, so why is the question suddenly back on the table, and why is it proving so hard to answer?

My guest is Dr Alan Rumsey, one of the genuine authorities in this field. Alan chaired the IEEE working group that wrote the original CBTC standard, and he has spent a 45-year career on advanced train control projects across North America, Europe and Asia.

We start by getting our terms straight, because in this industry the same word too often means different things to different people. From there we work through the real questions. Why would a railway want interoperable CBTC at all? What does interoperability actually mean once you get specific about it? And if the business case stacks up, how could the industry ever get there? Along the way we look at why New York took 25 years and a fortune to achieve it, why ETCS managed what CBTC has not, and what China's interoperable standard might mean for the established suppliers.

If you find this useful, subscribe and pass it on to a colleague who would get something from it.

If this conversation has got you wanting to go deeper, visit my training platform at www.docfranktraining.com. There you find the most comprehensive suite of online courses in advanced railway signalling anywhere. CBTC, ETCS, high capacity signalling, and more. All in one place, all vendor neutral.

Transcript

0:04

Ellen Ramsey, welcome to the show. Well, thank you, Doc Frank, or Frank, I'm going to just call you Frank. That's fine. I actually did think about changing my name on the screen here to Doc Alan, but I thought that would get too confusing. So anyway, it's good to meet up with you again and looking forward to our discussions on topics that we're both very, very interested in and passionate about. Yes, it's good to meet you again. Thanks. Thanks very much. First of all, before we get into this conversation, I wanted to comment you for your reliability. It's now mid-January. We set this appointment up before Christmas and I was thinking in the last few days, should I send Ellen a reminder or not? And then I thought, no, that's not necessary. He will be there. And sure as hell. You were there on time, even a few minutes beforehand. And I think personally that aligns a lot with my values, because I think if you want to be one of the greats in the industry, it's not just about what you know. It's also that you're doing what you say you would do. And showing up on time to meetings and appointments is to me personally one of the things that is important. And I'm very glad that you seem to share the same values. So kudos for that. Right. I think one of the topics that we talked about before and which we wanted to get back to is the topic of interoperability for CBTC. As a bit of background, I participated a few months ago in a study group that was organized by the IEEE, the organization that you used to work for before when you started the first version of the CBTC standards, IEEE 1474. So they now had a study group for the topic of interoperability. And that made me think about this entire topic and do a bit of research what other people are doing elsewhere in the world. And I ended up writing an article which will be in the IRS e-news in February. And then I talked to you about it because, I mean, obviously you are one of the all time greats of CBTC. And I was just so curious what you would think of that concept, whether you think it's completely crazy or whether you think it has merit. So I completely got you cold and I must say you answered, you were very open minded and you answered very constructively. But then I think after the conversation, you started thinking a little bit more about this and said, oh, wait a minute, maybe I can fine tune this and maybe there are a few aspects that are still worth discussing. So when you said, let's have another chat about interoperability, I thought that might be very interesting because now both you and I have a more elaborate view on it. Yeah, you're correct. It's something that obviously has been a part of my background, having been involved in the early days in New York where interoperability was a major concern. But sitting back and thinking on it, I thought what may help our discussions if we think of it in terms of the why, what and how and what I mean by that is, well, why do we need interoperability? We've had CBTC for 40 years now without interoperability. It's sort of become the global standard for metro signalling without interoperability. So why do we need interoperability? What's the business case? What's driving interoperability, both from an agency perspective and a supplier perspective? So I thought we could talk about that a little bit and that then gets us into what? Well, what do we mean by interoperability in a CBTC context? I think it's very clear what interoperability means in an ETCS context. Is CBTC the same or is it different? Is it different interfaces we're talking about? Is it more complex? Is it the same? And then hopefully that will lead us into how, you know, if we if there's a business case for interoperability, we know what we mean by interoperability. Then how do we get there? And I think that's where you particularly have had some some thoughts about how to get from where we are today to a point in the future where interoperability is, you know, maybe achievable. And another thought I had, maybe just to kick this thing off, is is when we use the phrase CBTC, what actually do we mean? I think you and I both commented in the past that we're in an industry where acronyms and terminology can sometimes mean different things to different people. So it might be worth just spending a minute or two to make sure that when we're talking about CBTC, we're actually all talking about the same thing and not talking about something, something different. Yes. Yes. That's a good idea. I'm a big fan of clarity in my own practice, both as a consultant and as a trainer, because if you want to explain things to people, then you've got to have clear definitions. And one of the big issues that I see, even with experienced people in the industry, is that they, they tend to get confused because they're using the same terms in a conversation, but in different ways. And then you start getting crosstalk between, between different people. And I find that clarifications once in a while help a lot to avoid those confusions. And then meetings just run better, getting more productive, the outcome becomes better. So I'm very happy to do that. Do you want to go ahead and kick off what CBTC means to you? Or do you want me to give my view of the world? Well, you can start off if you like, Frank. Right. So in my trainings, I'm doing CBTC training courses for eight years now, and I realized that there are different types of CBTC. So what, what you cannot prevent, and I tried this before and I have it right here in my hometown, where we have a railway organization or an agency, as you would call it in Canada, that did a new signaling project. So next generation signaling for a heavy haul mining railway. And for reasons that I'm not, I'm not privy of, they chose the term CBTC for that signaling application. And it's an application, it's a specific solution for this particular railway. And they chose to call it CBTC. And what I realized during the tender process, where I was briefly involved in, that it created a lot of confusion between the suppliers. So I spoke to several CBTC suppliers or signaling suppliers that have CBTC, but also other signaling technologies in their portfolio. And they said, Frank, we don't understand this. We don't understand this whole procurement. I mean, it's a freight railway. And how can they ask for CBTC? Do they really mean CBTC like in metro CBTC, or do they mean something entirely different? And on the basis of that discussion, I thought I coined the term genuine CBTC. And what I mean by genuine CBTC is something that complies with the IEEE standards, with IEEE 1474, with regards to performance and with regards to functionality. And that was one differentiator which already kind of ruled out that mining signaling solution. And I spoke to the railway operator as well, and they agreed that, yes, they call it CBTC and there's nothing I can do about it. But they acknowledged that it was not conforming with IEEE 1474. So I thought calling it genuine CBTC would be the best possible way of doing it. What would you think? Yeah, I reflected on an article I authored a few years ago, actually, for the International Technical Committee of the IRC called CBTC a product or a strategy? Uh-huh. And that's, I think, when I've thought about it more is important. Are we looking at CBTC as a product? Yeah, you can go to all of the major suppliers out there and say, show me your CBTC product. Yeah. And they'll all look pretty well the same. They will comply with IEEE 1474.1. And the system architecture will be somewhat similar. But as we know, they're not mix and match. You have to take the supplier's product or the supplier's product. Then I think if you look at CBTC not as a product or as a strategy and go back to the basics, you know, how have we defined CBTC in 1474.1? There's really three components. A positioning system that's train-borne, that doesn't rely on track circuits. Computer systems, both on the train and on the wayside, that are capable of performing safety-critical vital functions. And the communication network that ties all of those three things together. So that, to me, is the core of CBTC. And if you take a step back and look at it from a big picture point of view, you know, not so many decades ago, none of those things did exist. We didn't have computers. Communications were very basic. We relied on the good old track circuits to find out where trains were. And Singling managed quite well with that for many decades. And then all of a sudden computers came along, communications came along, smarter trains came along that knew where they are. And for me, at its core, CBTC then opens the world up. If you've got trains and know where they are, you've got powerful computers on the train and on the wayside, and you've got a communication system that links them together, you can pretty well do whatever you want with that. You know, you've got now the foundation that you can change the metro world, in effect. You can now do things that you couldn't do before. And yeah, 1474.1 lists a whole set of functions that a current CBTC system can do. But that really isn't the limit. Given train positioning, communications, powerful computers on trains that can do vital functions, we could do a lot more with that concept of CBTC than we're currently doing. And that, I think, then creates the dilemma. If you think of CBTC as a strategy that can evolve as positioning systems evolve, as communication systems evolve, as computer systems evolve, then that sort of contrary to goes against setting up a standard. If you think a CBTC of a product, then it makes a lot of sense to say, well, we've got this product. We've got a number of suppliers that can provide this product. So let's make a standard. We'll standardize the system architecture. We'll standardize the interfaces between the subsystems. And now we've got this great product that can be supplied by multiple suppliers, which is sort of the ETCS model. And for me, when I look at innovation, I always try and differentiate between doing the same thing differently and doing something different, doing something new. And with ETCS, at its core, it's really doing the same thing differently. It's a train protection system that's replacing a whole slew of different train protection systems that were scattered around Europe and combining it to do something. So it's really doing its product that's doing the same thing differently. Whereas I look at CBTC as something that enables us to do different things, allows us to do more than we were currently able to do, that the technology is enabling us to do more. So that, to me, is the big conflict I have when I think about interoperability, is once you establish a standard, you've inevitably constrained evolution. You've constrained innovation to some degree, because you're now boxed into a certain architecture. Because I think back in the 1980s, after the Vancouver Skytrain and the Detroit Downtown and the Pupil Mover and the Scarborough RT line, where many deserve it, we said, wow, this is fabulous. This inductive loop-based CBTC is fantastic. Let's write a standard around this inductive loop-based CBTC and get a whole load of suppliers that can produce components for this. That would have really prevented us going into a radio-based CBTC. Yeah. We're at a similar roadblock here where there's tremendous evolution going on at the moment in terms of train positioning systems. Well, ETCS and CBTC is currently based on a train positioning system that relies on transponders in the track. We have an opportunity to move away from that and have autonomous trains that don't need transponders in the track. If I built my standards around a positioning system that requires transponders in the track, so half of my trains are relying on transponders in the track, I can't now easily transition to a system that doesn't need transponders. I think that's a big dilemma that we have to face with interoperability is, on one side, what are the benefits? On another side, what are the disbenefits? Okay, yeah. When I thought about this whole confusion thing and how to create clarity, I looked at all the things that I picked up where there was obviously some confusion in conversations. Then I thought about a model how I could explain this in order to clarify it. I came up with a three-layer model. The top layer is technology, then a layer next down to it is product, and then there's the layer applications. At the time, that helped me to explain or to sort out all kinds of confusions. For example, I came across an example where people said, we're doing a technology selection between ETCS and CELTREC. I thought, well, wait a minute, you're talking about two different things because CELTREC is a product, a CBTC product from one single supplier. You know quite well that Stylis, you worked for them. I did work for them at a time. It's two different things. You can't compare ETCS with CELTREC. You can only compare ETCS against CBTC because both are on the same level of what I call technologies, whereas CELTREC is a product. What I said is technologies are the things that are getting standardized. There are standards for CBTC. There are standards for ETCS. Products is what you can purchase from the supplier. If you go to Stylis and you say, I want your Stylis CBTC, they will offer you CELTREC. If you go to Alstom, they will offer you Orbalis. If you go to Siemens, they will offer you Trangard MT and so on. Then you've got the third layer applications. This is where I could sort out this CBTC issue that I was discussing earlier. An application is what the client calls it. Toronto, for example, they're calling their CBTC application on line one, Automatic Train Control. They're not calling it CBTC. They're calling it Automatic Train Control. That's the name of their application. Somewhere else here in Australia, for example, we have applications of CBTC that are called High Capacity Signaling. It's the same thing. It's the same technology. It's CBTC in both cases, but the applications are called in a different way. By differentiating between technology products and applications, so far I was able to clarify all those confusions and to get people in my training courses clearer in their heads saying, okay, well, if this term is used as the name of an application by a single railway, but this is the term used for a technology which is standardized in IEEE 1474, now that makes a lot of sense to me. We had a previous discussion after you issued your paper on the 2nd of January, and I had a bit of a tickle at you there because I was trying to impose that thought model on what you've written in your paper. Maybe that wasn't quite fair because I spent a lot of thought about it. And obviously, you can look at these terms in different ways. So, for example, what you refer to as a product is not entirely wrong because you can use the word product in different meanings. So, your meaning is absolutely spot on, but it's different than the way that I'm using product in my three-layer model. That's just what it was. What you refer to as a strategy is important to think about innovation and stuff like that. But at the end of the day, if I go out to a railway as a consultant, I want to advise them on things that they can actually buy in the marketplace because normally people get me in and say, Frank, we want to upgrade our signaling system. We want to introduce a new generation of signaling. What can we do? And it doesn't make sense for me to advise them on a strategy that doesn't exist in the marketplace. I need to advise them on a technology where I know that products exist in the marketplace so that if they go to procurement in 12 months time or so, they can write a specification and the supply market will be able to respond to that procurement and offer them products that have a comparable functionality, comparable performance. So, if I look at ETCS, for example, that's a pretty good example. You've got a technology, you've got standards around it. Different suppliers have different products. They're called Atlas and Trangard 100, 200, and the Thales product is called L-Track and so on. And then in the background, you've got the European Rail Agency and the supplier association thinking about improvements, for example, satellite-based positioning. But these are at this point in time research projects, if you will. And once these research projects reach a certain level of maturity, then they will think about how can we add this to the ETCS standards? How can we make this part of the ETCS technology and innovate the ETCS technology, bring it forward? And once we've got the standards expanded, then the suppliers can go out and expand their products to still create interoperable ETCS products with extended functionality, if that makes sense. So, at the moment, for example, they're introducing automatic train operation into the ETCS world. They call it ATO over ETCS, and they are currently working on an interoperable standard for ATO over ETCS, which will become part of the next version of the ETCS standards. And once this is the case, then you will get to an interoperable version of ATO in the ETCS world, and all the ETCS products that incorporate ATO will be on an interoperable level. That means that onboard systems from different suppliers can operate on trackside systems from different suppliers. Yeah, I'm with you. I agree there is this game terminology issue. Yeah. Because for me, in the little blurb that I put on LinkedIn, which was my sort of data dump, which seemed to create a lot of interest, is that I regarded ETCS as an ATP product. Yes. Because that's the way the European Union describes it. If you look at, if you go to the IU frequency, they ask questions. It said ETCS is an automatic train protection system. And it's replacing automatic train protection systems that previously existed in different countries. So the interoperability in the European sense is that I can operate a train across the country borders seamlessly without having to switch equipment and change over equipment. It's all seamlessly. So, and as I tried to point out in the note I put on LinkedIn, interoperability from an operational sense means that you've got the same, is it technology, same product? Let's say the same product. You've got the same system. If you have the same system on the whole lines, on the whole rail corridor, then you have an interoperable corridor. If the train is equipped with that system and the whole wayside is equipped with that system, you have interoperability. But the key, what ETCS adds to that is that system, that product, that technology, whatever labour you want to put on it, is actually available from multiple suppliers. So sometimes we use the word interoperability in the sense of an operator, from an operator's perspective, I can operate my train on the whole corridor. And sometimes we use it in the sense of multiple, it's interoperable because I can get it from multiple suppliers. And I think we have to be careful that we make that distinction. I use Vancouver SkyTrain as an example. There was the original SkyTrain line. There's been multiple extensions and new lines added to the network. And it's an interoperable network. The same train can operate on any of the lines and any of the extensions because it's equipped with the same system. So achieving operate, you know, it would be nice if parts of the system could have been obtained from different suppliers from a commercial point of view, but from the operator's perspective, they have interoperability. So that's where I make this distinction. Interoperability with a single supplier is easy. Interoperability with multiple suppliers for commercial reasons is complicated. And so I think we need to understand why we're looking for interoperability. And this debate over, you know, what I was trying to argue is I see ETCS as a product in the sense, if I'm going out to the market and I want to purchase an automatic train protection system for my fixed block railway, I've got multiple products I can choose from. I don't have to go with ETCS. I could go with TPWS, Chinese model. There's numerous products out there that essentially provide the same functionality as ETCS. They provide overspeed protection and red signal enforcement. So in that sense, there are a lot of ATP products. One of them is called ETCS. And ETCS has the advantage that you can procure it from multiple suppliers. Each supplier may give a different name to what they call their product, just like each CBTC supplier gives their CBTC products a different name. But in the ETCS world, they're really the same product because the onboard equipment does exactly the same thing, the wayside equipment does exactly the same thing, same communications and so on. Yeah, I mean, I don't want to cut this too fine or basically hammer this issue too hard. But what I find it's getting confusing, potentially confusing at least, if a certain term is used in two different meanings at the same time. So you're talking about ETCS as a product, which to me is fine. Personally, I understand your definition, especially once we talked about it and you explain what you mean by that. But at the same time, we're talking about products such as how the suppliers call it. So you could say that in the CBTC world, Celtrec is a product, Obalys is a product, and Trangard MT is a product. So where the confusion could come in, if somebody says CBTC is a product and somebody else says Celtrec is a product, that they just mix up CBTC with Celtrec. And to me, Celtrec is an expression, if you will, of the technology CBTC. So I'm basically introducing a second terminology, which is technology for CBTC, for ETCS, just to avoid using the term product on two different levels, if you know what I mean. At the end of the day, it doesn't really matter. To me personally, as a trainer, it does matter if I feel confusion anywhere because I'm trying to mitigate that confusion. And this three-layer model that I have taught in my training courses helps me doing that. And it has worked every time that if people were confused after I explained these three models and said, look, ETCS belongs to this technology layer and something like Celtrec or Ltrec or Trangard or whatever belongs to that product category, people normally understood it and the confusion just dissipated. Okay. Well, maybe just to wrap this piece of discussion up so we can move on, I think to use your technology then in the CBTC world, I would say we could say CBTC is a technology and Celtrec and Trangard and Obalis are CBTC products or products within the group of CBTC technologies. Yes. But my analogy then would be is the comparison is we have automatic train protection technologies for fixed box signaling systems. And within that ATP technology, we have numerous products, which include ETCS, TPWS, AXIS, the products in the US that are products that provide ATP functionality for fixed box signal territory. Yeah. You just said what I was about to say. You have basically expanded my thought model. I had my three-layer thought model and then I read your article and I think how does ATP fit in there? ATP is not really a technology, at least not in my definition. ATP is not a product and ATP is not an application. I mean, people can call their stuff ATP. That's fine. But so I needed to introduce a fourth level to the thought model, which comes on top of the technologies. And that's, as you said, the functionality level. So the functionality in this case, again, that's my definition, my expanded thought concept, the functionality would be ATP. Underneath, you've got different technologies and ETCS is one of these technologies. So I'm still in line with my previous thought model calling ETCS a technology. And other ATP technologies are technologies as well. So if you take LSAT-B from Germany, that would be a technology for ATP. If you take TVM from France, if you take positive train control in America, for example, that would be a technology providing automatic train protection. And then underneath, you've got your product level and product in my definition, which is as clear as it can get. Product is what the suppliers call it. So that would be your Xs or your ETCS products for positive train control. For CBTC, it would be your Celtrex, your Obalysis and so on. And for ETCS, it would be your Eltrek, your Atlas, your Trangard 100, 200 and so on. So this ATP would basically be in a top layer category called functionalities. And for CBTC, that functionality would be automatic train control in my understanding. And there are other technologies that provide automatic train control. So CBTC would be one of them. Some people argue ETCS would be one of them. And yeah, that is kind of borderline. But you do have other technologies. For example, the Japanese system, which is called ATEX or something like that. That's something that provides automatic train control. You've got distance to go systems in the UK, for example. They provide automatic train control. Yeah, but I think you're right. We can probably wrap this up and move to somewhere else, talking about interoperability and why that's required. Yeah, I'd be interested because you've always looked at it really closely. What is, going back now, purely the CBTC world, is there truly a business case for interoperability in the sense of being able to provide a CBTC system with components from multiple suppliers? Now, we know New York's been struggling for two decades to do that. Paris has something equivalent. We'll probably talk more later about what the Chinese initiative. But again, going back to the fact that we seem to have managed without it for 40 years, and notwithstanding the lack of interoperability, CBTC has become the sort of ad hoc industry standard for metro singling. I'll do a plug for the IRC here, their recent textbook. 500 pages in here, and it talks almost exclusively about CBTC in terms of metro train control systems. So what is it now that is driving the need for interoperability? Since all our experience, the ETCS experience, New York experience, that it's not a trivial activity. Actually, producing an interoperable CBTC system available from multiple suppliers is very complicated, very time consuming. If this conversation makes you wanting to go deeper, I run what I believe is the most comprehensive portfolio of online training courses in advanced railway signaling. CBTC, ETCS, high-capacity signaling, and more. You find them all at my own training platform, dogfranktraining.com. That's dogfranktraining.com. And everything is right there waiting for you. But now, back to the show. So what is the business case that's driving it? Okay, and I'm using, I've got a response to that, and I'm using New York as a beautiful example for that. So you do have some metro networks that basically consist of standalone lines, either because there's only one line end to end anyway, or if we have multiple lines, they are separated from each other. So you can do on each line pretty much whatever you want. So Singapore is a good example. You've got lines, for example, the Northeast line, which is completely separated from the Northeast line. Yes, North-South and Northeast are two lines which are completely separated. I'll take North-South and Circle, for example. So what you can do and what they have done is to use one CBTC supplier on the one line end to end. So the entire line is fitted wayside with CBTC of that one supplier. And all the trains, every train on that line operating is fitted with CBTC onboard from the same supplier. So to me, this is not interoperability. For me, this is just one supplier delivering their solution and it works. And on the other line, there's a different CBTC supplier, both for wayside and for onboard on every train operating on the other line. And interoperability between those two lines is not required because the two lines are not connected. There's no train from the one line that will ever have to go on to the other line. So what I define as interoperability in this case is not required. Now, if you compare that with a network like New York, for example, where you've got many different lines coming together and then sharing a central piece of corridor, a trunk line, if you will, this will make it very, very hard to follow the same model, to have a single CBTC supplier for everything. Because if you have a CBTC supplier for the central trunk section, that same supplier would also have to fit all the lines that are coming out of this trunk section. So in New York, basically, you have this differentiation between division A and division B. So it would basically mean that your entire division A network would have to be fitted by one supplier and the entire division B network by a different supplier. Maybe the same, maybe a different. And this is something that New York didn't want. They said, well, look, our division A is huge. That's a network in itself. We cannot rely for the entire network for a single supplier. We have to have multiple suppliers. But then we have the problem of interoperability that these two different products of those two suppliers, they don't talk to each other. They are not interoperable. So for New York, we need to come up with a solution for interoperability. You know that you were involved in the planning process. And you also know how long it took New York, how expensive it was for them to get to interoperability and how painful it was. It took them 25 years to get there. And I've just done a paper. Now I'm doing a paper in summer, probably on a conference in Australia. I've done a video on New York based on your paper and some later updates. So the interoperability journey of New York was extremely painful. Now, if I advise a client here in Australia, for example, so if a network like Melbourne wants to introduce CBTC and they have a network of lines that are interconnected, so basically like New York, not quite the same, but they also have interconnected lines, which means that they either have to go for a model where they have a single supplier for the entire network. But then they say, wait a minute, our network is too big. We can't afford this. We need to have multiple suppliers. And then you immediately have this interoperability problem. And you say, well, we don't have interoperable products of CBTC. What do we do? And then you need to start thinking about cutting apart the lines, like segregating the lines, which is a huge impact if the operation was based on trains changing between lines and so on. And Melbourne is currently failing because of that. Yeah. So they find it just too difficult to make this line segregation. And as a consequence, guess what? They're moving away from CBTC. They're now looking at ETCS because they say we need to have an interoperable solution and CBTC in its current state is not it. So now you may have the data that I don't have, but if we looked at the total global metro market, there is probably some line somewhere where on one side of that line, the metro systems are simple enough that requiring multiple supplier interoperability is maybe always desirable, but maybe not essential. There's a lot of metros that have installed CBTC already and I think are quite happy with the fact of the particular supplier they've selected. But I agree, there's a line somewhere that once a network becomes very complex and New York is maybe the ultimate example, you seriously do have to consider an interoperable solution. And this is what took New York down its path and it's what's taken Paris down its path. And there may be another half a dozen metros out there in the world that feel they have to go down that path as well. There are other big networks like Hong Kong that have gone the single supplier route. And so I agree that there is a market somewhere there that would benefit from an interoperable solution. But then the problem comes, let's take the solution that New York has come up with and the solution that Paris has come up with, are those two solutions interoperable? No. You know, because Paris is operational needs and New York's operational needs and the history of both agencies is such that even if we had an interoperable solution, is it a solution that would be purchased by multiple agencies? Well, I mean, the New York solution clearly is interoperable. So the situation in New York at the moment is that they have a pool of three CBTC suppliers, which is Taras Siemens and Mitsubishi, and they can choose between those three suppliers. So what New York could do is they can choose a certain line of their network and they can cut the line into three parts and they can say, okay, one part we're fitting with CBTC Wayside from Siemens, one with CBTC Wayside from Taras and the third part with CBTC Wayside from Mitsubishi. And the train fleet can have CBTC onboard from any of those three suppliers and it will work. So this is interoperability and New York has gotten there after 25 years and a lot of pain and a lot of effort, a lot of money. Finally, they've gotten there. What you said, which is 100% correct, is that the solution for New York is so specific, is so bespoke that it's not readily transferable to other railways. You could not take the New York solution. And I've asked the question, I've asked suppliers, if I have an interoperability requirement for CBTC in Australia, couldn't we use the New York solution and transfer it to Australia? And even the suppliers who did the solution for New York, they said that doesn't work because New York is so specific. They have very specific interfaces. They're interfacing to relay interlockings, which are very specific to the US market. They've got certain operational rules that seem to be very unique to New York. So I'm entirely with you. It's interoperable, but it's not migratable. So that means that an agency here in Australia, for example, or take any other city with a network that requires interoperability, let's take London. That's a nice example. Because London Underground, and you know London quite well, so that's why I'm choosing this. And London Underground does have interoperability requirements in their network. And at the moment, they actually have an interoperability problem, even though their entire CBTC on the entire network so far comes from a single supplier. But where the interoperability problem is that on two of the lines, they have chosen CBTC based on induction loops. And on the other lines, they have chosen CBTC radio-based. And now they have two lines coming together. One of the lines is fitted with induction loop CBTC, and the other line is fitted with radio-based CBTC from the same company, from the same supplier, and it's not interoperable, which is ironic if you think about it. So what do networks like this, and I mean London is not a Mickey Mouse network. London is one of the biggest metros in the world, and one of the most prominent metros in the world. What do networks like this do other than either going for a single supplier solution, which they're trying, or following the path of New York, where everybody can see in the world how painful it was, how terribly expensive it was, and how long it took them to get there. London doesn't want to wait 25 years for an interoperable CBTC. Melbourne wouldn't want to wait 25 years for an interoperable CBTC. No network provider with interoperability requirements wants to wait 25 years and go through the pain that New York has gone through. So you are right. We need to look at how big is this market. Is it attractive or not? And honestly, I've spoken to suppliers recently and they said to me, well, look, Frank, 90% of our prospective clients are not asking for CBTC interoperability. We are quite happy to serve those 90% with our product and ignore the other 10%. That's fine, but it does create a problem for those 10%. And what's happening now in the marketplace is that there has been an interoperable CBTC standard developed in China. And now all of a sudden we have an interoperable CBTC solution from China potentially coming into the world market. And now what I said in an article in the IRSE news a couple of years ago or so about CBTC interoperability, I said if China starts exporting this interoperable CBTC into the world, what will be the response of the Western established supply market? The likes of Alstom, Siemens, Thales, and so on. Do they have a response? I don't think they do. So how are we going from here? And at the time I didn't have an answer and now I dug a little bit deeper and at least now I've got an idea how it could work. We now basically have two different segments of the supply market. One market where products are not interoperable. That's the IEEE word, if you will. And then we've got this Chinese corner over there compliant with the KEMET standards, which are interoperable. And when customers have a choice between those two options, everything else being equal, I could well imagine that they tend to go for the interoperable solution rather than the established one. And that would be something that's certainly hurting the market share of the Western industry. That was one of my main points. A couple of things I'll respond to. What little I know, the LU's problem is they will come up with an LU solution. Because I believe the supplier will be able to come up with an onboard unit that's capable of receiving inputs from either a radio or a loop. Because it's still, although it's a different communication mechanism, the radio version of CellTrack evolved from the inductive loop version of CellTrack. So the high level architecture is still very similar. So I think without interoperability, that's sort of the path that will happen, is that agencies will have to work out, if they have two different products, they'll have to work out a solution that enables that to operate. It's going in exactly the opposite direction of ETCS. But if I've got a train that's going to operate on one system on one track, and on another system on another track, then I can equip the train. Not very desirable, but it's probably a lot cheaper than maybe spending 25 years to develop an interoperable solution, perhaps. I don't know. I'm just throwing things out here. Because again, another example from London is the Elizabeth line. Crossrail. There's a system that's interoperable. It can go from the east to the west, through central London, where the wayside is equipped with ETCS, TPWS, CBTC. That's accommodated by the train. That's a smart train that can accommodate ETCS when it's on ETCS territory, CBTC when it's in CBTC territory, and TPWS when it's in TPWS. These acronyms, they kill you, don't they, after a while? Yeah, yeah, yeah. So there are... Crossrail, it's maybe not an elegant solution. It certainly created technical challenges at the borders to how to deal with it. But as far as I know, they've achieved an interoperable line with multiple wayside sets of equipment. And then your final comment about the Chinese initiative is certainly very interesting. They've certainly done a lot of effort in developing standards, interoperable interfaces. As far as I know, these standards are not available in English yet. So it's a little difficult. And I don't know to what extent they've been fully validated and safety certified and so on with multiple suppliers. But again, the underlying worry there is, in my 40 years of implementing CBTC around the world, I don't know two agencies that have had the same specification. Every agency has their unique set of requirements. Every CBTC product requires somewhere between 20% and 80% of the software to be reworked to meet the agency-specific requirement. So a standard that's been developed for the Chinese metro market, is that going to be acceptable to a global market? I don't know. You know, ETCS have the advantage that it's mandated by law. So if you want to put in ETCS, you have to put in this version of ETCS. So it's a little difficult there. Yeah, it's a fascinating topic because one can see conceptually, academically, if you like, all the benefits of an interoperable multiple supplier solution. But again, to actually get there, there has to be a process that could get us there. And that process is only going to work if there's a business case, not only for the agencies, but for the suppliers. Yes. And that's the challenge. Yes, yes. And that's one of the most interesting factors when I did my research on interoperability, which is leading to that paper that is coming out in February in the RSC News, where I looked at different interoperability initiatives and ETCS was one of them. And then what New York did with CVTC, then I looked at the Paris approach. I looked at the IEEE standards, the established standards, which today are not providing interoperability. And then I compared them and I thought about why are some of these approaches successful? Why do they lead to interoperability and others don't? And I found a common set of drivers that can either help an approach getting towards interoperability or preventing it from getting to interoperability. And the point that you said, is there a business case is in fact very, very relevant because one, you need a business case from the agency perspective. So I call this market pull. For ETCS, it's a legal mandate in Europe that ETCS has to be used. So that's the market pull. A supplier that wants to do automatic train protection in Europe has to have ETCS and has to have ETCS according to the standards. So for them, it's a requirement to participate in the marketplace. So that's a market pull. If they don't want to do ETCS, they can't play in that European market. And therefore they do play because the market is attractive enough. New York, similar story. New York said, well, look, we've got this huge network, which supplier would be interested in developing an interoperable CVTC. Solution. And the carrot for that is that they are allowed to participate in the New York CVTC market. And there were at least three suppliers who said, this looks attractive enough for us to go through the pain and effort and cost to develop an interoperable solution so that we can participate in the New York market. And the same is in China. In China, there is this China association of metros, and they said, we are developing these interoperable standards. Anybody who wants to do CVTC in China on a Chinese metro, and there are heaps of them needs to comply with those standards. And guess what? Everybody complied. And it didn't matter whether they had existing products that didn't comply and they had to change the products, which is a big obstacle at the moment for all these Western suppliers. So if, for example, the IEEE standards were expanded towards interoperability, that would mean that some of the existing CVTC products would no longer be compliant with those new standards. So suppliers would have to go back and change their products or create a second version of the product that complies with the new interoperable standards. And that's a financial effort that most suppliers are not willing to date, are not willing to go for. Where you say, is there a business case for the suppliers? And the answer in most cases so far has been, no, there isn't. That's why suppliers don't go for it. But it may change in the future. Yeah. Just to briefly go back to New York. It really wasn't a case of three suppliers getting together and agreeing on developing an interoperable product. It was actually a leader-follower process. So one system was selected. It was the Matra system, now the Siemens system. And then the other two suppliers had to adapt their products or create a new product that was compatible. And that's the dilemma with the IEEE approach or any sort of consensus-driven approach, is you have to come up with a system architecture first and decide on a standard system in order to define the interface. And of course, each supplier will lobby to get the standard system to be as close as possible to their existing system. So getting a consent, you know, ETCS was a little easier because in a way, everybody was starting with a clean sheet of paper. Yes. So it was a little bit easier, but it's not so easy in the CBTC world. Well, I'm conscious we're bumping up against our one-hour limit. And I think we both knew this would probably go on longer. Yeah. I wonder, is this an appropriate point to sort of bring this to some breaking point? Probably, yeah. I just wanted to respond to one thing. Everything you just said is 100% correct. And you already identified, basically off the cuff, some of the drivers that I identified. So for ETCS, as you said, they started on a clean sheet of paper, which is a strong driver or a strong prerequisite to come to a set of standards that really do provide interoperability. So everywhere where people start on a clean sheet of paper and they have the standard first, and then they develop the products according to the standards, they have a fair chance of ending up with an interoperable solution. That's what happened with ETCS. For CBTC, you also mentioned another good point. The standardization process of the IEEE is consensus-based. And if you have five suppliers in the room with five different technical solutions in detail for CBTC, different functional allocations, and so on, and every supplier tries to pull the standard into the direction of their product, they will never come to an agreement. Never. And so to me, that's the reason why the IEEE, I don't think, has a fair chance of getting to an interoperable set of standards. Because they want to reach consensus with suppliers that don't want a consensus unless it looks like their solution and it doesn't. And on the other hand, the IEEE has absolutely no leverage to force suppliers into anything. Like even if they did write a complete new set of standards, which was providing for interoperability, they have no way of enforcing that. So the only party that could enforce it would be the railway agencies. And they are normally not powerful enough or not invested enough or whatever to do that. So I think we covered a lot of reasons why interoperability for CBTC is such a problem. And... It's not only the five different suppliers that are in the room. There's also the five different agencies in the room. And, you know, one end of the spectrum, you've got an operator of maybe a very simple light rail line that all he wants is some ATP and he's not interested in ATO. The other end of the spectrum, you've got an operator that's operating a GOA4 system, fully driverless system. So it's not only getting a consensus amongst the suppliers, it's also getting a consensus among the users in terms of this standard delivering a product that's going to meet their specific needs. So... Yeah, but at the end of the day, if you look at how the interoperable standards look like, for instance, for ETCS or also for the New York solution, it's predominantly an agreement on the interface specifications between wayside and onboard. It does not necessarily say which features are involved in that. It just defines a communication protocol and that certain functions are either living on the wayside or on the onboard. That's this allocation thing. If you look at ETCS, for example, you've got, I don't know, say 10,000 features of ETCS. And if a railway only wants to use five of them, that's perfectly okay. But you still have an interface specification between wayside and onboard that would allow you to transmit communication for all 10,000 features. Regardless of whether you only take five of them or 150 or 3,000, it doesn't matter. The interface specification always stands. The protocol is there. The language is there. And on that basis, you could introduce additional innovations in the future. You just need to make sure anytime there's a communication between wayside and onboard, you need to make sure that your interface standard includes this bit of communication. That's all there is. So if you look at ATO over ETCS at the moment, the only thing that's getting standardized is the protocol of the communication between wayside and onboard. What the onboard does with it doesn't matter. How the wayside gets to the commands doesn't matter. And every supplier can do this in a different way. But whenever there is communication required, that has to be standardized because that would be the breaking of interoperability if that's not done right. Yeah, again, looking at the New York I2S specs, it's not just one interface that's captured in there in their specifications. There's maybe 10 or 12 interfaces that are captured in their specifications because of the functionality. But if you're going to pass information from one system to another, you need to know what information is going to be passed and what you're supposed to do with it. Yes, yes. So these are the intricacies. If you have a piece of line that's cut in the middle and one supplier's doing the wayside on one part of the line, the other supplier's doing CVTC on the other part, they need to communicate wayside to wayside. So yeah, that's right. That's understood. But the main aspect of interoperability is really the train not being able to communicate with the wayside. So the train to wayside interface is really the most critical one that needs to be addressed in interoperability. So yeah, I think that's probably a good time to wrap this up if anybody is interested to see what my suggestion is, how the Western industry could come to a potentially interoperable solution, then feel free to read my article on the RSE News. So there's the little plug for that. I heard that you have got an intention to elaborate further on your paper that you dropped on LinkedIn in early January and transform this into a paper for the RSE News, which will probably come, what do you say, April or May or something like that? Yeah, I was approached by RSE to say if they could put my LinkedIn article in March or April, I think, whenever they've got an empty slot, I guess. Yeah, yeah. And I'm happy for them to do that. And I'll tweak it a little bit. I got a lot of good comments came back on my LinkedIn article and where I can, I'll try to incorporate those in a sort of update that will come out. So yeah, I think maybe just to summarise, I think the very fact that this topic is getting aired in the industry is good. The response is back to my LinkedIn article, and I'm sure the response is back to your RSE article, which I'm very much looking forward to reading. You know, this is all beneficial. It's all moves, hopefully moves the industry forward in a positive way. Yes, and if it doesn't, then at least they do so with open eyes. I mean, suppliers are obviously free to just ignore the whole thing and to say, well, look, we just keep selling our existing CBTC product and we keep innovating it. And we keep marketing that this innovation is really an obstacle to all this interoperability developments, and it's the best to just buy this one product. And that works as long as it works. And then if parts of the market are getting steamrolled by an interoperable Chinese solution, then so be it. Maybe some suppliers say, now we want to do this differently. Maybe some railway agencies wake up and say, hey, if we are really keen on an interoperable solution, we need to think about what our role is in the entire process. Maybe we need to create an agency such as the ERA in Europe for ETCS, a system authority that can foster the development of interoperable standards on our behalf. I don't know, but it opens all kinds of interesting angles on this discussion, which I think is generally good for the industry. And it just creates clarity where people can see with open eyes, okay, well, this is what I'm doing. This is what I'm not doing. And here's the reason why. So I can't say I didn't know any other way because you and I have written these papers. So it's out in the public. There is another way, or there may be more than one way. And then they can make a decision with open eyes. Am I going this way? Am I going that way? And I think this is what good consultancy is for. And also what thought leadership is for, which I think we're currently practicing to some degree with that discussion. And yeah, and I hope that this conversation here was interesting for the readers as much as the upcoming papers will be interesting. And I'd like to thank you for your contribution. I always like talking to you very, very much. And I hope that wasn't the last one. And I'm pretty sure we will find lots of other topics regarding to CBTC and the wider railways that are very, very interesting. I know that the topic of innovation is very close to your heart. I know that you have kind of complained that of the original ideas for CBTC, only a relatively small fraction has so far been implemented. And deployed into real products, which is a bit of a shame. So there will be some headway for the future for further innovations. And maybe we can pick up that discussion another time. Okay. My pleasure, Frank. It's been great talking to you and really, really good discussions. So thank you very much for the invitation. Hi, it's Doc Frank again. I hope you enjoyed this conversation. If you like the content, then the best way you make sure that you don't miss out on any of the future episodes, just subscribe to the channel. By doing so, you also get access to all the previous episodes, which I'm pretty sure there will be many that are of interest to you. Another thing that you can do to help not just your own environment, but the entire industry is to share this episode with friends and coworkers, because it helps more people in our industry to get educated and an educated rail signaling industry is a better industry. With that said, thank you very much. Hope to see you again soon. And bye for now.