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

WEBVTT
00:00:04.799 --> 00:00:06.759
Ellen Ramsey, welcome to the show.
00:00:08.599 --> 00:00:12.439
Well, thank you, Doc Frank, or Frank, I'm going to just call you Frank.
00:00:13.000 --> 00:00:13.519
That's fine.
00:00:15.660 --> 00:00:22.160
I actually did think about changing my name on the screen here to Doc Alan, but I thought that would get too confusing.
00:00:22.519 --> 00:00:32.740
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.
00:00:32.979 --> 00:00:34.439
Yes, it's good to meet you again.
00:00:34.979 --> 00:00:35.299
Thanks.
00:00:35.399 --> 00:00:36.159
Thanks very much.
00:00:36.600 --> 00:00:42.679
First of all, before we get into this conversation, I wanted to comment you for your reliability.
00:00:43.240 --> 00:00:44.500
It's now mid-January.
00:00:44.679 --> 00:00:52.740
We set this appointment up before Christmas and I was thinking in the last few days, should I send Ellen a reminder or not?
00:00:52.780 --> 00:00:54.640
And then I thought, no, that's not necessary.
00:00:54.799 --> 00:00:55.520
He will be there.
00:00:55.899 --> 00:00:57.399
And sure as hell.
00:00:57.399 --> 00:01:00.299
You were there on time, even a few minutes beforehand.
00:01:01.219 --> 00:01:11.260
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.
00:01:11.540 --> 00:01:15.000
It's also that you're doing what you say you would do.
00:01:15.239 --> 00:01:20.900
And showing up on time to meetings and appointments is to me personally one of the things that is important.
00:01:21.120 --> 00:01:24.239
And I'm very glad that you seem to share the same values.
00:01:24.620 --> 00:01:26.000
So kudos for that.
00:01:30.469 --> 00:01:30.829
Right.
00:01:30.969 --> 00:01:40.189
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.
00:01:40.709 --> 00:01:57.450
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.
00:01:58.150 --> 00:02:01.650
So they now had a study group for the topic of interoperability.
00:02:02.010 --> 00:02:09.389
And that made me think about this entire topic and do a bit of research what other people are doing elsewhere in the world.
00:02:09.930 --> 00:02:14.830
And I ended up writing an article which will be in the IRS e-news in February.
00:02:15.669 --> 00:02:21.669
And then I talked to you about it because, I mean, obviously you are one of the all time greats of CBTC.
00:02:21.889 --> 00:02:28.270
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.
00:02:28.849 --> 00:02:36.909
So I completely got you cold and I must say you answered, you were very open minded and you answered very constructively.
00:02:37.430 --> 00:02:49.490
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.
00:02:49.729 --> 00:03:01.069
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.
00:03:02.669 --> 00:03:04.509
Yeah, you're correct.
00:03:04.889 --> 00:03:16.849
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.
00:03:18.069 --> 00:03:31.370
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?
00:03:32.389 --> 00:03:36.310
We've had CBTC for 40 years now without interoperability.
00:03:37.009 --> 00:03:43.270
It's sort of become the global standard for metro signalling without interoperability.
00:03:43.530 --> 00:03:46.770
So why do we need interoperability?
00:03:46.930 --> 00:03:48.270
What's the business case?
00:03:48.270 --> 00:03:55.330
What's driving interoperability, both from an agency perspective and a supplier perspective?
00:03:55.909 --> 00:04:00.770
So I thought we could talk about that a little bit and that then gets us into what?
00:04:00.830 --> 00:04:06.090
Well, what do we mean by interoperability in a CBTC context?
00:04:06.550 --> 00:04:11.729
I think it's very clear what interoperability means in an ETCS context.
00:04:12.210 --> 00:04:14.430
Is CBTC the same or is it different?
00:04:14.629 --> 00:04:18.069
Is it different interfaces we're talking about?
00:04:18.269 --> 00:04:19.569
Is it more complex?
00:04:19.750 --> 00:04:20.750
Is it the same?
00:04:21.509 --> 00:04:32.050
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.
00:04:32.470 --> 00:04:34.170
Then how do we get there?
00:04:34.250 --> 00:04:48.329
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.
00:04:49.629 --> 00:05:00.750
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?
00:05:01.750 --> 00:05:11.149
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.
00:05:12.209 --> 00:05:23.569
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.
00:05:24.189 --> 00:05:24.370
Yes.
00:05:24.629 --> 00:05:24.910
Yes.
00:05:24.990 --> 00:05:26.050
That's a good idea.
00:05:26.170 --> 00:05:36.610
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.
00:05:37.329 --> 00:05:48.850
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.
00:05:48.850 --> 00:05:53.269
And then you start getting crosstalk between, between different people.
00:05:53.269 --> 00:06:00.649
And I find that clarifications once in a while help a lot to avoid those confusions.
00:06:00.649 --> 00:06:04.970
And then meetings just run better, getting more productive, the outcome becomes better.
00:06:05.149 --> 00:06:07.949
So I'm very happy to do that.
00:06:07.949 --> 00:06:12.050
Do you want to go ahead and kick off what CBTC means to you?
00:06:12.329 --> 00:06:15.889
Or do you want me to give my view of the world?
00:06:17.790 --> 00:06:20.310
Well, you can start off if you like, Frank.
00:06:20.769 --> 00:06:21.069
Right.
00:06:21.370 --> 00:06:31.370
So in my trainings, I'm doing CBTC training courses for eight years now, and I realized that there are different types of CBTC.
00:06:31.649 --> 00:06:46.529
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.
00:06:46.769 --> 00:06:50.990
So next generation signaling for a heavy haul mining railway.
00:06:52.170 --> 00:07:00.750
And for reasons that I'm not, I'm not privy of, they chose the term CBTC for that signaling application.
00:07:01.350 --> 00:07:05.550
And it's an application, it's a specific solution for this particular railway.
00:07:06.300 --> 00:07:08.689
And they chose to call it CBTC.
00:07:09.110 --> 00:07:18.470
And what I realized during the tender process, where I was briefly involved in, that it created a lot of confusion between the suppliers.
00:07:18.670 --> 00:07:27.329
So I spoke to several CBTC suppliers or signaling suppliers that have CBTC, but also other signaling technologies in their portfolio.
00:07:27.930 --> 00:07:30.529
And they said, Frank, we don't understand this.
00:07:30.569 --> 00:07:32.089
We don't understand this whole procurement.
00:07:32.269 --> 00:07:34.250
I mean, it's a freight railway.
00:07:34.769 --> 00:07:36.870
And how can they ask for CBTC?
00:07:37.170 --> 00:07:43.089
Do they really mean CBTC like in metro CBTC, or do they mean something entirely different?
00:07:44.170 --> 00:07:49.810
And on the basis of that discussion, I thought I coined the term genuine CBTC.
00:07:50.230 --> 00:08:02.290
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.
00:08:02.990 --> 00:08:12.350
And that was one differentiator which already kind of ruled out that mining signaling solution.
00:08:13.269 --> 00:08:20.670
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.
00:08:20.850 --> 00:08:26.970
But they acknowledged that it was not conforming with IEEE 1474.
00:08:26.970 --> 00:08:32.788
So I thought calling it genuine CBTC would be the best possible way of doing it.
00:08:32.889 --> 00:08:33.970
What would you think?
00:08:36.658 --> 00:08:51.960
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?
00:08:52.960 --> 00:08:54.000
Uh-huh.
00:08:55.840 --> 00:08:59.720
And that's, I think, when I've thought about it more is important.
00:09:00.000 --> 00:09:02.639
Are we looking at CBTC as a product?
00:09:02.980 --> 00:09:10.919
Yeah, you can go to all of the major suppliers out there and say, show me your CBTC product.
00:09:11.340 --> 00:09:11.500
Yeah.
00:09:11.500 --> 00:09:13.320
And they'll all look pretty well the same.
00:09:13.759 --> 00:09:22.840
They will comply with IEEE 1474.1. And the system architecture will be somewhat similar.
00:09:23.639 --> 00:09:26.100
But as we know, they're not mix and match.
00:09:26.179 --> 00:09:30.480
You have to take the supplier's product or the supplier's product.
00:09:31.700 --> 00:09:43.440
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?
00:09:43.940 --> 00:09:45.600
There's really three components.
00:09:46.159 --> 00:09:51.779
A positioning system that's train-borne, that doesn't rely on track circuits.
00:09:53.159 --> 00:10:04.000
Computer systems, both on the train and on the wayside, that are capable of performing safety-critical vital functions.
00:10:04.539 --> 00:10:09.779
And the communication network that ties all of those three things together.
00:10:10.460 --> 00:10:13.340
So that, to me, is the core of CBTC.
00:10:14.000 --> 00:10:23.279
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.
00:10:23.379 --> 00:10:25.159
We didn't have computers.
00:10:26.480 --> 00:10:29.019
Communications were very basic.
00:10:29.820 --> 00:10:33.379
We relied on the good old track circuits to find out where trains were.
00:10:34.879 --> 00:10:38.360
And Singling managed quite well with that for many decades.
00:10:39.100 --> 00:10:47.960
And then all of a sudden computers came along, communications came along, smarter trains came along that knew where they are.
00:10:49.000 --> 00:10:54.460
And for me, at its core, CBTC then opens the world up.
00:10:55.840 --> 00:11:08.399
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.
00:11:08.639 --> 00:11:17.740
You know, you've got now the foundation that you can change the metro world, in effect.
00:11:18.019 --> 00:11:20.679
You can now do things that you couldn't do before.
00:11:22.860 --> 00:11:31.019
And yeah, 1474.1 lists a whole set of functions that a current CBTC system can do.
00:11:31.639 --> 00:11:33.179
But that really isn't the limit.
00:11:34.019 --> 00:11:47.840
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.
00:11:49.080 --> 00:11:51.379
And that, I think, then creates the dilemma.
00:11:51.940 --> 00:12:09.539
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.
00:12:10.779 --> 00:12:16.659
If you think a CBTC of a product, then it makes a lot of sense to say, well, we've got this product.
00:12:16.759 --> 00:12:20.139
We've got a number of suppliers that can provide this product.
00:12:20.399 --> 00:12:21.720
So let's make a standard.
00:12:22.100 --> 00:12:24.419
We'll standardize the system architecture.
00:12:24.740 --> 00:12:28.659
We'll standardize the interfaces between the subsystems.
00:12:28.659 --> 00:12:38.679
And now we've got this great product that can be supplied by multiple suppliers, which is sort of the ETCS model.
00:12:40.379 --> 00:12:54.919
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.
00:12:55.879 --> 00:13:02.240
And with ETCS, at its core, it's really doing the same thing differently.
00:13:03.100 --> 00:13:12.879
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.
00:13:13.080 --> 00:13:17.679
So it's really doing its product that's doing the same thing differently.
00:13:18.419 --> 00:13:32.399
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.
00:13:33.659 --> 00:13:52.059
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.
00:13:52.360 --> 00:13:59.419
You've constrained innovation to some degree, because you're now boxed into a certain architecture.
00:14:00.799 --> 00:14:15.299
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.
00:14:15.620 --> 00:14:19.799
This inductive loop-based CBTC is fantastic.
00:14:20.519 --> 00:14:29.840
Let's write a standard around this inductive loop-based CBTC and get a whole load of suppliers that can produce components for this.
00:14:30.860 --> 00:14:35.559
That would have really prevented us going into a radio-based CBTC.
00:14:35.559 --> 00:14:36.220
Yeah.
00:14:37.080 --> 00:14:46.000
We're at a similar roadblock here where there's tremendous evolution going on at the moment in terms of train positioning systems.
00:14:47.679 --> 00:14:54.919
Well, ETCS and CBTC is currently based on a train positioning system that relies on transponders in the track.
00:14:55.700 --> 00:15:05.320
We have an opportunity to move away from that and have autonomous trains that don't need transponders in the track.
00:15:06.100 --> 00:15:24.759
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.
00:15:25.340 --> 00:15:35.179
I think that's a big dilemma that we have to face with interoperability is, on one side, what are the benefits?
00:15:35.840 --> 00:15:38.500
On another side, what are the disbenefits?
00:15:39.220 --> 00:15:40.179
Okay, yeah.
00:15:41.080 --> 00:15:52.740
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.
00:15:53.600 --> 00:16:00.100
Then I thought about a model how I could explain this in order to clarify it.
00:16:00.519 --> 00:16:03.639
I came up with a three-layer model.
00:16:03.639 --> 00:16:13.500
The top layer is technology, then a layer next down to it is product, and then there's the layer applications.
00:16:14.299 --> 00:16:20.179
At the time, that helped me to explain or to sort out all kinds of confusions.
00:16:20.299 --> 00:16:29.340
For example, I came across an example where people said, we're doing a technology selection between ETCS and CELTREC.
00:16:30.159 --> 00:16:39.840
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.
00:16:40.139 --> 00:16:42.860
You know quite well that Stylis, you worked for them.
00:16:42.940 --> 00:16:44.980
I did work for them at a time.
00:16:45.500 --> 00:16:46.659
It's two different things.
00:16:46.840 --> 00:16:49.779
You can't compare ETCS with CELTREC.
00:16:49.899 --> 00:17:01.000
You can only compare ETCS against CBTC because both are on the same level of what I call technologies, whereas CELTREC is a product.
00:17:02.360 --> 00:17:07.160
What I said is technologies are the things that are getting standardized.
00:17:07.519 --> 00:17:08.960
There are standards for CBTC.
00:17:09.220 --> 00:17:10.618
There are standards for ETCS.
00:17:11.160 --> 00:17:14.358
Products is what you can purchase from the supplier.
00:17:15.420 --> 00:17:21.480
If you go to Stylis and you say, I want your Stylis CBTC, they will offer you CELTREC.
00:17:21.618 --> 00:17:24.400
If you go to Alstom, they will offer you Orbalis.
00:17:24.400 --> 00:17:27.900
If you go to Siemens, they will offer you Trangard MT and so on.
00:17:28.519 --> 00:17:30.819
Then you've got the third layer applications.
00:17:31.099 --> 00:17:36.000
This is where I could sort out this CBTC issue that I was discussing earlier.
00:17:36.900 --> 00:17:39.700
An application is what the client calls it.
00:17:40.559 --> 00:17:46.420
Toronto, for example, they're calling their CBTC application on line one, Automatic Train Control.
00:17:47.140 --> 00:17:48.380
They're not calling it CBTC.
00:17:48.579 --> 00:17:50.119
They're calling it Automatic Train Control.
00:17:50.319 --> 00:17:52.480
That's the name of their application.
00:17:52.480 --> 00:17:59.539
Somewhere else here in Australia, for example, we have applications of CBTC that are called High Capacity Signaling.
00:18:00.460 --> 00:18:01.660
It's the same thing.
00:18:01.759 --> 00:18:02.799
It's the same technology.
00:18:03.000 --> 00:18:07.559
It's CBTC in both cases, but the applications are called in a different way.
00:18:08.099 --> 00:18:37.519
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.
00:18:39.200 --> 00:18:53.019
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.
00:18:53.140 --> 00:18:56.759
Maybe that wasn't quite fair because I spent a lot of thought about it.
00:18:57.039 --> 00:19:00.099
And obviously, you can look at these terms in different ways.
00:19:00.559 --> 00:19:08.019
So, for example, what you refer to as a product is not entirely wrong because you can use the word product in different meanings.
00:19:08.500 --> 00:19:16.420
So, your meaning is absolutely spot on, but it's different than the way that I'm using product in my three-layer model.
00:19:16.759 --> 00:19:17.680
That's just what it was.
00:19:18.039 --> 00:19:27.039
What you refer to as a strategy is important to think about innovation and stuff like that.
00:19:27.339 --> 00:19:41.319
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.
00:19:41.319 --> 00:19:43.559
We want to introduce a new generation of signaling.
00:19:44.019 --> 00:19:45.240
What can we do?
00:19:45.779 --> 00:19:51.599
And it doesn't make sense for me to advise them on a strategy that doesn't exist in the marketplace.
00:19:52.019 --> 00:20:17.220
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.
00:20:18.059 --> 00:20:21.819
So, if I look at ETCS, for example, that's a pretty good example.
00:20:21.920 --> 00:20:24.700
You've got a technology, you've got standards around it.
00:20:25.299 --> 00:20:27.599
Different suppliers have different products.
00:20:27.740 --> 00:20:34.099
They're called Atlas and Trangard 100, 200, and the Thales product is called L-Track and so on.
00:20:35.640 --> 00:20:45.740
And then in the background, you've got the European Rail Agency and the supplier association thinking about improvements, for example, satellite-based positioning.
00:20:46.559 --> 00:20:51.359
But these are at this point in time research projects, if you will.
00:20:52.519 --> 00:21:02.859
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?
00:21:02.859 --> 00:21:10.740
How can we make this part of the ETCS technology and innovate the ETCS technology, bring it forward?
00:21:11.500 --> 00:21:25.700
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.
00:21:25.839 --> 00:21:31.539
So, at the moment, for example, they're introducing automatic train operation into the ETCS world.
00:21:31.539 --> 00:21:46.740
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.
00:21:47.359 --> 00:22:03.019
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.
00:22:03.299 --> 00:22:12.400
That means that onboard systems from different suppliers can operate on trackside systems from different suppliers.
00:22:16.480 --> 00:22:19.160
Yeah, I'm with you.
00:22:19.339 --> 00:22:23.420
I agree there is this game terminology issue.
00:22:23.680 --> 00:22:23.880
Yeah.
00:22:23.880 --> 00:22:43.039
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.
00:22:43.480 --> 00:22:43.680
Yes.
00:22:43.680 --> 00:22:46.859
Because that's the way the European Union describes it.
00:22:46.859 --> 00:22:51.680
If you look at, if you go to the IU frequency, they ask questions.
00:22:51.880 --> 00:22:56.400
It said ETCS is an automatic train protection system.
00:22:57.579 --> 00:23:04.140
And it's replacing automatic train protection systems that previously existed in different countries.
00:23:05.859 --> 00:23:23.019
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.
00:23:23.519 --> 00:23:24.920
It's all seamlessly.
00:23:25.559 --> 00:23:41.619
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?
00:23:41.740 --> 00:23:43.359
Let's say the same product.
00:23:43.359 --> 00:23:45.380
You've got the same system.
00:23:46.700 --> 00:23:55.460
If you have the same system on the whole lines, on the whole rail corridor, then you have an interoperable corridor.
00:23:56.059 --> 00:24:04.160
If the train is equipped with that system and the whole wayside is equipped with that system, you have interoperability.
00:24:05.000 --> 00:24:16.599
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.
00:24:17.839 --> 00:24:29.299
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.
00:24:29.900 --> 00:24:38.539
And sometimes we use it in the sense of multiple, it's interoperable because I can get it from multiple suppliers.
00:24:39.680 --> 00:24:43.599
And I think we have to be careful that we make that distinction.
00:24:46.339 --> 00:24:49.619
I use Vancouver SkyTrain as an example.
00:24:50.359 --> 00:24:52.539
There was the original SkyTrain line.
00:24:52.700 --> 00:24:56.930
There's been multiple extensions and new lines added to the network.
00:24:58.019 --> 00:25:00.000
And it's an interoperable network.
00:25:00.400 --> 00:25:07.339
The same train can operate on any of the lines and any of the extensions because it's equipped with the same system.
00:25:08.160 --> 00:25:23.160
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.
00:25:23.839 --> 00:25:25.680
So that's where I make this distinction.
00:25:27.420 --> 00:25:30.259
Interoperability with a single supplier is easy.
00:25:32.079 --> 00:25:36.920
Interoperability with multiple suppliers for commercial reasons is complicated.
00:25:37.339 --> 00:25:42.500
And so I think we need to understand why we're looking for interoperability.
00:25:43.839 --> 00:26:04.119
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.
00:26:04.400 --> 00:26:06.500
I don't have to go with ETCS.
00:26:06.500 --> 00:26:13.400
I could go with TPWS, Chinese model.
00:26:14.759 --> 00:26:23.019
There's numerous products out there that essentially provide the same functionality as ETCS.
00:26:23.279 --> 00:26:27.559
They provide overspeed protection and red signal enforcement.
00:26:28.640 --> 00:26:32.740
So in that sense, there are a lot of ATP products.
00:26:33.460 --> 00:26:35.480
One of them is called ETCS.
00:26:35.480 --> 00:26:41.039
And ETCS has the advantage that you can procure it from multiple suppliers.
00:26:43.240 --> 00:26:55.500
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.
00:26:56.799 --> 00:27:09.059
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.
00:27:10.339 --> 00:27:19.319
Yeah, I mean, I don't want to cut this too fine or basically hammer this issue too hard.
00:27:19.539 --> 00:27:30.759
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.
00:27:30.759 --> 00:27:35.880
So you're talking about ETCS as a product, which to me is fine.
00:27:36.500 --> 00:27:42.160
Personally, I understand your definition, especially once we talked about it and you explain what you mean by that.
00:27:42.720 --> 00:27:48.380
But at the same time, we're talking about products such as how the suppliers call it.
00:27:48.680 --> 00:27:58.420
So you could say that in the CBTC world, Celtrec is a product, Obalys is a product, and Trangard MT is a product.
00:27:59.180 --> 00:28:11.240
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.
00:28:11.940 --> 00:28:20.420
And to me, Celtrec is an expression, if you will, of the technology CBTC.
00:28:20.799 --> 00:28:35.599
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.
00:28:35.720 --> 00:28:38.220
At the end of the day, it doesn't really matter.
00:28:38.660 --> 00:28:45.799
To me personally, as a trainer, it does matter if I feel confusion anywhere because I'm trying to mitigate that confusion.
00:28:46.380 --> 00:28:51.059
And this three-layer model that I have taught in my training courses helps me doing that.
00:28:51.180 --> 00:29:12.619
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.
00:29:14.599 --> 00:29:14.779
Okay.
00:29:15.359 --> 00:29:39.619
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.
00:29:39.880 --> 00:29:39.980
Yes.
00:29:40.559 --> 00:29:53.740
But my analogy then would be is the comparison is we have automatic train protection technologies for fixed box signaling systems.
00:29:54.940 --> 00:30:20.660
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.
00:30:20.940 --> 00:30:21.099
Yeah.
00:30:21.220 --> 00:30:23.660
You just said what I was about to say.
00:30:24.160 --> 00:30:27.319
You have basically expanded my thought model.
00:30:27.480 --> 00:30:35.519
I had my three-layer thought model and then I read your article and I think how does ATP fit in there?
00:30:36.279 --> 00:30:39.839
ATP is not really a technology, at least not in my definition.
00:30:40.359 --> 00:30:43.779
ATP is not a product and ATP is not an application.
00:30:43.960 --> 00:30:45.920
I mean, people can call their stuff ATP.
00:30:46.059 --> 00:30:46.460
That's fine.
00:30:46.460 --> 00:30:55.920
But so I needed to introduce a fourth level to the thought model, which comes on top of the technologies.
00:30:56.180 --> 00:30:58.660
And that's, as you said, the functionality level.
00:30:59.380 --> 00:31:07.579
So the functionality in this case, again, that's my definition, my expanded thought concept, the functionality would be ATP.
00:31:08.579 --> 00:31:13.220
Underneath, you've got different technologies and ETCS is one of these technologies.
00:31:13.220 --> 00:31:20.339
So I'm still in line with my previous thought model calling ETCS a technology.
00:31:21.000 --> 00:31:25.039
And other ATP technologies are technologies as well.
00:31:25.119 --> 00:31:30.099
So if you take LSAT-B from Germany, that would be a technology for ATP.
00:31:30.460 --> 00:31:41.079
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.
00:31:41.609 --> 00:31:47.940
And then underneath, you've got your product level and product in my definition, which is as clear as it can get.
00:31:48.539 --> 00:31:50.900
Product is what the suppliers call it.
00:31:51.480 --> 00:31:57.960
So that would be your Xs or your ETCS products for positive train control.
00:31:58.099 --> 00:32:01.720
For CBTC, it would be your Celtrex, your Obalysis and so on.
00:32:01.759 --> 00:32:09.059
And for ETCS, it would be your Eltrek, your Atlas, your Trangard 100, 200 and so on.
00:32:09.059 --> 00:32:18.240
So this ATP would basically be in a top layer category called functionalities.
00:32:19.059 --> 00:32:24.079
And for CBTC, that functionality would be automatic train control in my understanding.
00:32:24.740 --> 00:32:29.539
And there are other technologies that provide automatic train control.
00:32:29.700 --> 00:32:31.460
So CBTC would be one of them.
00:32:31.839 --> 00:32:35.039
Some people argue ETCS would be one of them.
00:32:35.599 --> 00:32:38.079
And yeah, that is kind of borderline.
00:32:38.480 --> 00:32:40.480
But you do have other technologies.
00:32:41.099 --> 00:32:48.579
For example, the Japanese system, which is called ATEX or something like that.
00:32:49.339 --> 00:32:52.440
That's something that provides automatic train control.
00:32:53.059 --> 00:32:56.880
You've got distance to go systems in the UK, for example.
00:32:57.220 --> 00:32:59.220
They provide automatic train control.
00:33:00.299 --> 00:33:01.720
Yeah, but I think you're right.
00:33:01.720 --> 00:33:09.519
We can probably wrap this up and move to somewhere else, talking about interoperability and why that's required.
00:33:10.859 --> 00:33:15.180
Yeah, I'd be interested because you've always looked at it really closely.
00:33:17.539 --> 00:33:39.619
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?
00:33:40.200 --> 00:33:45.220
Now, we know New York's been struggling for two decades to do that.
00:33:45.799 --> 00:33:47.420
Paris has something equivalent.
00:33:48.539 --> 00:33:52.000
We'll probably talk more later about what the Chinese initiative.
00:33:53.519 --> 00:34:10.340
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.
00:34:15.559 --> 00:34:20.579
I'll do a plug for the IRC here, their recent textbook.
00:34:21.480 --> 00:34:29.820
500 pages in here, and it talks almost exclusively about CBTC in terms of metro train control systems.
00:34:30.699 --> 00:34:38.059
So what is it now that is driving the need for interoperability?
00:34:39.119 --> 00:34:49.039
Since all our experience, the ETCS experience, New York experience, that it's not a trivial activity.
00:34:49.039 --> 00:34:59.119
Actually, producing an interoperable CBTC system available from multiple suppliers is very complicated, very time consuming.
00:35:01.579 --> 00:35:12.400
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.
00:35:13.079 --> 00:35:17.159
CBTC, ETCS, high-capacity signaling, and more.
00:35:17.840 --> 00:35:22.400
You find them all at my own training platform, dogfranktraining.com.
00:35:22.880 --> 00:35:25.699
That's dogfranktraining.com.
00:35:26.079 --> 00:35:28.579
And everything is right there waiting for you.
00:35:28.980 --> 00:35:30.860
But now, back to the show.
00:35:33.719 --> 00:35:36.719
So what is the business case that's driving it?
00:35:37.139 --> 00:35:43.840
Okay, and I'm using, I've got a response to that, and I'm using New York as a beautiful example for that.
00:35:43.840 --> 00:35:57.460
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.
00:35:57.579 --> 00:36:01.519
So you can do on each line pretty much whatever you want.
00:36:01.880 --> 00:36:03.880
So Singapore is a good example.
00:36:04.239 --> 00:36:14.159
You've got lines, for example, the Northeast line, which is completely separated from the Northeast line.
00:36:14.619 --> 00:36:18.559
Yes, North-South and Northeast are two lines which are completely separated.
00:36:18.659 --> 00:36:20.699
I'll take North-South and Circle, for example.
00:36:21.460 --> 00:36:29.619
So what you can do and what they have done is to use one CBTC supplier on the one line end to end.
00:36:29.800 --> 00:36:34.079
So the entire line is fitted wayside with CBTC of that one supplier.
00:36:34.079 --> 00:36:42.159
And all the trains, every train on that line operating is fitted with CBTC onboard from the same supplier.
00:36:42.460 --> 00:36:44.380
So to me, this is not interoperability.
00:36:44.599 --> 00:36:48.559
For me, this is just one supplier delivering their solution and it works.
00:36:49.199 --> 00:36:58.659
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.
00:36:59.300 --> 00:37:05.920
And interoperability between those two lines is not required because the two lines are not connected.
00:37:06.260 --> 00:37:11.219
There's no train from the one line that will ever have to go on to the other line.
00:37:11.480 --> 00:37:15.480
So what I define as interoperability in this case is not required.
00:37:16.039 --> 00:37:40.599
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.
00:37:40.960 --> 00:37:52.519
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.
00:37:52.980 --> 00:37:57.639
So in New York, basically, you have this differentiation between division A and division B.
00:37:57.980 --> 00:38:10.159
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.
00:38:10.300 --> 00:38:11.619
Maybe the same, maybe a different.
00:38:12.079 --> 00:38:14.239
And this is something that New York didn't want.
00:38:14.239 --> 00:38:17.780
They said, well, look, our division A is huge.
00:38:18.019 --> 00:38:19.480
That's a network in itself.
00:38:19.940 --> 00:38:25.179
We cannot rely for the entire network for a single supplier.
00:38:25.679 --> 00:38:28.440
We have to have multiple suppliers.
00:38:29.039 --> 00:38:36.900
But then we have the problem of interoperability that these two different products of those two suppliers, they don't talk to each other.
00:38:37.639 --> 00:38:39.280
They are not interoperable.
00:38:39.840 --> 00:38:44.079
So for New York, we need to come up with a solution for interoperability.
00:38:44.239 --> 00:38:46.780
You know that you were involved in the planning process.
00:38:47.300 --> 00:38:56.000
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.
00:38:56.199 --> 00:38:58.900
It took them 25 years to get there.
00:38:59.760 --> 00:39:02.199
And I've just done a paper.
00:39:02.300 --> 00:39:06.739
Now I'm doing a paper in summer, probably on a conference in Australia.
00:39:06.739 --> 00:39:12.340
I've done a video on New York based on your paper and some later updates.
00:39:12.980 --> 00:39:17.480
So the interoperability journey of New York was extremely painful.
00:39:18.260 --> 00:39:44.099
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.
00:39:44.659 --> 00:39:46.980
But then they say, wait a minute, our network is too big.
00:39:47.079 --> 00:39:47.980
We can't afford this.
00:39:48.099 --> 00:39:49.679
We need to have multiple suppliers.
00:39:50.340 --> 00:39:53.480
And then you immediately have this interoperability problem.
00:39:53.880 --> 00:39:59.219
And you say, well, we don't have interoperable products of CBTC.
00:39:59.440 --> 00:40:00.139
What do we do?
00:40:00.139 --> 00:40:15.760
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.
00:40:16.420 --> 00:40:19.179
And Melbourne is currently failing because of that.
00:40:19.619 --> 00:40:19.840
Yeah.
00:40:19.900 --> 00:40:24.320
So they find it just too difficult to make this line segregation.
00:40:24.619 --> 00:40:26.460
And as a consequence, guess what?
00:40:26.780 --> 00:40:28.420
They're moving away from CBTC.
00:40:29.179 --> 00:40:39.380
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.
00:40:41.280 --> 00:41:15.500
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.
00:41:16.460 --> 00:41:25.619
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.
00:41:26.139 --> 00:41:43.199
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.
00:41:45.500 --> 00:41:51.880
And this is what took New York down its path and it's what's taken Paris down its path.
00:41:52.380 --> 00:41:58.679
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.
00:41:59.400 --> 00:42:07.280
There are other big networks like Hong Kong that have gone the single supplier route.
00:42:08.000 --> 00:42:21.119
And so I agree that there is a market somewhere there that would benefit from an interoperable solution.
00:42:22.099 --> 00:42:34.239
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?
00:42:34.460 --> 00:42:34.760
No.
00:42:35.389 --> 00:43:00.900
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?
00:43:01.840 --> 00:43:07.119
Well, I mean, the New York solution clearly is interoperable.
00:43:07.320 --> 00:43:20.239
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.
00:43:20.380 --> 00:43:38.559
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.
00:43:39.099 --> 00:43:46.639
And the train fleet can have CBTC onboard from any of those three suppliers and it will work.
00:43:47.039 --> 00:43:54.519
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.
00:43:54.900 --> 00:43:56.340
Finally, they've gotten there.
00:43:56.780 --> 00:44:10.599
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.
00:44:10.980 --> 00:44:14.280
You could not take the New York solution.
00:44:14.420 --> 00:44:28.679
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?
00:44:29.340 --> 00:44:37.840
And even the suppliers who did the solution for New York, they said that doesn't work because New York is so specific.
00:44:38.139 --> 00:44:40.179
They have very specific interfaces.
00:44:40.380 --> 00:44:45.940
They're interfacing to relay interlockings, which are very specific to the US market.
00:44:45.940 --> 00:44:51.159
They've got certain operational rules that seem to be very unique to New York.
00:44:51.539 --> 00:44:53.280
So I'm entirely with you.
00:44:53.440 --> 00:44:56.179
It's interoperable, but it's not migratable.
00:44:56.920 --> 00:45:07.860
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.
00:45:08.000 --> 00:45:09.260
That's a nice example.
00:45:09.739 --> 00:45:15.059
Because London Underground, and you know London quite well, so that's why I'm choosing this.
00:45:15.059 --> 00:45:20.559
And London Underground does have interoperability requirements in their network.
00:45:21.460 --> 00:45:31.840
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.
00:45:32.860 --> 00:45:41.079
But where the interoperability problem is that on two of the lines, they have chosen CBTC based on induction loops.
00:45:41.900 --> 00:45:45.980
And on the other lines, they have chosen CBTC radio-based.
00:45:46.619 --> 00:45:49.460
And now they have two lines coming together.
00:45:49.900 --> 00:46:05.239
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.
00:46:05.719 --> 00:46:10.059
So what do networks like this, and I mean London is not a Mickey Mouse network.
00:46:10.059 --> 00:46:14.800
London is one of the biggest metros in the world, and one of the most prominent metros in the world.
00:46:15.300 --> 00:46:36.079
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.
00:46:36.079 --> 00:46:41.820
London doesn't want to wait 25 years for an interoperable CBTC.
00:46:42.239 --> 00:46:46.940
Melbourne wouldn't want to wait 25 years for an interoperable CBTC.
00:46:47.400 --> 00:46:56.679
No network provider with interoperability requirements wants to wait 25 years and go through the pain that New York has gone through.
00:46:57.079 --> 00:46:58.719
So you are right.
00:46:58.840 --> 00:47:00.800
We need to look at how big is this market.
00:47:00.960 --> 00:47:02.440
Is it attractive or not?
00:47:02.440 --> 00:47:14.739
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.
00:47:15.199 --> 00:47:22.619
We are quite happy to serve those 90% with our product and ignore the other 10%.
00:47:25.050 --> 00:47:28.889
That's fine, but it does create a problem for those 10%.
00:47:29.190 --> 00:47:37.389
And what's happening now in the marketplace is that there has been an interoperable CBTC standard developed in China.
00:47:38.130 --> 00:47:48.869
And now all of a sudden we have an interoperable CBTC solution from China potentially coming into the world market.
00:47:49.590 --> 00:48:08.110
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?
00:48:08.449 --> 00:48:11.070
The likes of Alstom, Siemens, Thales, and so on.
00:48:11.250 --> 00:48:12.449
Do they have a response?
00:48:12.670 --> 00:48:13.849
I don't think they do.
00:48:14.510 --> 00:48:16.789
So how are we going from here?
00:48:17.909 --> 00:48:25.530
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.
00:48:26.030 --> 00:48:30.789
We now basically have two different segments of the supply market.
00:48:30.789 --> 00:48:34.789
One market where products are not interoperable.
00:48:35.170 --> 00:48:37.389
That's the IEEE word, if you will.
00:48:38.150 --> 00:48:45.809
And then we've got this Chinese corner over there compliant with the KEMET standards, which are interoperable.
00:48:46.570 --> 00:49:01.050
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.
00:49:01.170 --> 00:49:05.570
And that would be something that's certainly hurting the market share of the Western industry.
00:49:06.289 --> 00:49:08.210
That was one of my main points.
00:49:10.530 --> 00:49:12.929
A couple of things I'll respond to.
00:49:15.010 --> 00:49:21.389
What little I know, the LU's problem is they will come up with an LU solution.
00:49:22.769 --> 00:49:37.409
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.
00:49:38.050 --> 00:49:49.610
Because it's still, although it's a different communication mechanism, the radio version of CellTrack evolved from the inductive loop version of CellTrack.
00:49:49.769 --> 00:49:54.130
So the high level architecture is still very similar.
00:49:54.760 --> 00:50:13.010
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.
00:50:14.389 --> 00:50:18.369
It's going in exactly the opposite direction of ETCS.
00:50:18.909 --> 00:50:31.010
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.
00:50:31.550 --> 00:50:40.590
Not very desirable, but it's probably a lot cheaper than maybe spending 25 years to develop an interoperable solution, perhaps.
00:50:40.789 --> 00:50:41.409
I don't know.
00:50:41.630 --> 00:50:42.989
I'm just throwing things out here.
00:50:43.670 --> 00:50:47.769
Because again, another example from London is the Elizabeth line.
00:50:48.369 --> 00:50:48.949
Crossrail.
00:50:49.889 --> 00:50:53.130
There's a system that's interoperable.
00:50:53.309 --> 00:51:05.250
It can go from the east to the west, through central London, where the wayside is equipped with ETCS, TPWS, CBTC.
00:51:06.409 --> 00:51:08.849
That's accommodated by the train.
00:51:09.429 --> 00:51:24.329
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.
00:51:24.489 --> 00:51:26.590
These acronyms, they kill you, don't they, after a while?
00:51:26.670 --> 00:51:27.369
Yeah, yeah, yeah.
00:51:28.130 --> 00:51:28.590
So there are...
00:51:29.929 --> 00:51:32.730
Crossrail, it's maybe not an elegant solution.
00:51:33.510 --> 00:51:38.530
It certainly created technical challenges at the borders to how to deal with it.
00:51:39.210 --> 00:51:46.969
But as far as I know, they've achieved an interoperable line with multiple wayside sets of equipment.
00:51:47.989 --> 00:51:54.829
And then your final comment about the Chinese initiative is certainly very interesting.
00:51:56.110 --> 00:52:04.690
They've certainly done a lot of effort in developing standards, interoperable interfaces.
00:52:06.110 --> 00:52:09.250
As far as I know, these standards are not available in English yet.
00:52:09.429 --> 00:52:10.130
So it's a little difficult.
00:52:10.130 --> 00:52:17.070
And I don't know to what extent they've been fully validated and safety certified and so on with multiple suppliers.
00:52:17.869 --> 00:52:29.489
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.
00:52:31.010 --> 00:52:34.050
Every agency has their unique set of requirements.
00:52:34.769 --> 00:52:44.070
Every CBTC product requires somewhere between 20% and 80% of the software to be reworked to meet the agency-specific requirement.
00:52:44.969 --> 00:52:58.250
So a standard that's been developed for the Chinese metro market, is that going to be acceptable to a global market?
00:52:58.570 --> 00:52:59.690
I don't know.
00:52:59.690 --> 00:53:05.809
You know, ETCS have the advantage that it's mandated by law.
00:53:06.849 --> 00:53:11.190
So if you want to put in ETCS, you have to put in this version of ETCS.
00:53:11.389 --> 00:53:14.969
So it's a little difficult there.
00:53:15.909 --> 00:53:30.469
Yeah, it's a fascinating topic because one can see conceptually, academically, if you like, all the benefits of an interoperable multiple supplier solution.
00:53:32.250 --> 00:53:40.530
But again, to actually get there, there has to be a process that could get us there.
00:53:41.329 --> 00:53:48.409
And that process is only going to work if there's a business case, not only for the agencies, but for the suppliers.
00:53:48.750 --> 00:53:49.369
Yes.
00:53:50.050 --> 00:53:51.489
And that's the challenge.
00:53:52.010 --> 00:53:52.809
Yes, yes.
00:53:52.809 --> 00:54:11.010
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.
00:54:11.909 --> 00:54:17.530
And then what New York did with CVTC, then I looked at the Paris approach.
00:54:18.130 --> 00:54:24.889
I looked at the IEEE standards, the established standards, which today are not providing interoperability.
00:54:25.230 --> 00:54:31.170
And then I compared them and I thought about why are some of these approaches successful?
00:54:31.590 --> 00:54:35.150
Why do they lead to interoperability and others don't?
00:54:35.489 --> 00:54:47.769
And I found a common set of drivers that can either help an approach getting towards interoperability or preventing it from getting to interoperability.
00:54:47.769 --> 00:54:57.750
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.
00:54:58.070 --> 00:55:00.190
So I call this market pull.
00:55:00.809 --> 00:55:06.750
For ETCS, it's a legal mandate in Europe that ETCS has to be used.
00:55:06.869 --> 00:55:08.050
So that's the market pull.
00:55:08.469 --> 00:55:18.570
A supplier that wants to do automatic train protection in Europe has to have ETCS and has to have ETCS according to the standards.
00:55:19.010 --> 00:55:22.829
So for them, it's a requirement to participate in the marketplace.
00:55:23.469 --> 00:55:24.510
So that's a market pull.
00:55:24.769 --> 00:55:29.789
If they don't want to do ETCS, they can't play in that European market.
00:55:30.030 --> 00:55:33.070
And therefore they do play because the market is attractive enough.
00:55:33.670 --> 00:55:35.130
New York, similar story.
00:55:35.610 --> 00:55:44.829
New York said, well, look, we've got this huge network, which supplier would be interested in developing an interoperable CVTC.
00:55:44.829 --> 00:55:45.389
Solution.
00:55:46.190 --> 00:55:53.510
And the carrot for that is that they are allowed to participate in the New York CVTC market.
00:55:54.369 --> 00:56:08.949
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.
00:56:09.449 --> 00:56:10.849
And the same is in China.
00:56:10.849 --> 00:56:17.949
In China, there is this China association of metros, and they said, we are developing these interoperable standards.
00:56:18.429 --> 00:56:26.449
Anybody who wants to do CVTC in China on a Chinese metro, and there are heaps of them needs to comply with those standards.
00:56:26.730 --> 00:56:27.349
And guess what?
00:56:27.730 --> 00:56:28.829
Everybody complied.
00:56:29.710 --> 00:56:42.150
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.
00:56:43.429 --> 00:56:59.690
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.
00:57:00.369 --> 00:57:10.329
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.
00:57:10.809 --> 00:57:17.510
And that's a financial effort that most suppliers are not willing to date, are not willing to go for.
00:57:17.949 --> 00:57:21.309
Where you say, is there a business case for the suppliers?
00:57:21.510 --> 00:57:25.170
And the answer in most cases so far has been, no, there isn't.
00:57:25.769 --> 00:57:28.250
That's why suppliers don't go for it.
00:57:30.349 --> 00:57:32.590
But it may change in the future.
00:57:32.590 --> 00:57:33.469
Yeah.
00:57:34.170 --> 00:57:36.670
Just to briefly go back to New York.
00:57:36.949 --> 00:57:45.949
It really wasn't a case of three suppliers getting together and agreeing on developing an interoperable product.
00:57:46.489 --> 00:57:48.949
It was actually a leader-follower process.
00:57:49.269 --> 00:57:51.710
So one system was selected.
00:57:52.150 --> 00:57:55.230
It was the Matra system, now the Siemens system.
00:57:55.769 --> 00:58:02.590
And then the other two suppliers had to adapt their products or create a new product that was compatible.
00:58:03.670 --> 00:58:27.050
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.
00:58:27.650 --> 00:58:34.789
And of course, each supplier will lobby to get the standard system to be as close as possible to their existing system.
00:58:37.829 --> 00:58:45.250
So getting a consent, you know, ETCS was a little easier because in a way, everybody was starting with a clean sheet of paper.
00:58:45.610 --> 00:58:45.789
Yes.
00:58:46.250 --> 00:58:51.369
So it was a little bit easier, but it's not so easy in the CBTC world.
00:58:51.369 --> 00:58:59.190
Well, I'm conscious we're bumping up against our one-hour limit.
00:58:59.510 --> 00:59:02.369
And I think we both knew this would probably go on longer.
00:59:02.809 --> 00:59:02.909
Yeah.
00:59:02.969 --> 00:59:11.429
I wonder, is this an appropriate point to sort of bring this to some breaking point?
00:59:11.789 --> 00:59:12.730
Probably, yeah.
00:59:12.869 --> 00:59:15.190
I just wanted to respond to one thing.
00:59:15.289 --> 00:59:17.610
Everything you just said is 100% correct.
00:59:17.610 --> 00:59:22.650
And you already identified, basically off the cuff, some of the drivers that I identified.
00:59:23.210 --> 00:59:35.590
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.
00:59:36.389 --> 00:59:48.710
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.
00:59:48.869 --> 00:59:50.449
That's what happened with ETCS.
00:59:51.010 --> 00:59:54.269
For CBTC, you also mentioned another good point.
00:59:54.730 --> 00:59:59.369
The standardization process of the IEEE is consensus-based.
01:00:00.050 --> 01:00:20.429
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.
01:00:20.789 --> 01:00:20.969
Never.
01:00:22.269 --> 01:00:31.889
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.
01:00:32.170 --> 01:00:41.789
Because they want to reach consensus with suppliers that don't want a consensus unless it looks like their solution and it doesn't.
01:00:43.010 --> 01:00:50.449
And on the other hand, the IEEE has absolutely no leverage to force suppliers into anything.
01:00:50.730 --> 01:01:00.269
Like even if they did write a complete new set of standards, which was providing for interoperability, they have no way of enforcing that.
01:01:00.949 --> 01:01:05.829
So the only party that could enforce it would be the railway agencies.
01:01:06.710 --> 01:01:13.449
And they are normally not powerful enough or not invested enough or whatever to do that.
01:01:14.269 --> 01:01:21.309
So I think we covered a lot of reasons why interoperability for CBTC is such a problem.
01:01:23.570 --> 01:01:24.070
And...
01:01:26.429 --> 01:01:30.289
It's not only the five different suppliers that are in the room.
01:01:30.829 --> 01:01:33.610
There's also the five different agencies in the room.
01:01:34.449 --> 01:01:45.010
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.
01:01:45.309 --> 01:01:54.409
The other end of the spectrum, you've got an operator that's operating a GOA4 system, fully driverless system.
01:01:55.329 --> 01:02:09.389
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.
01:02:10.110 --> 01:02:10.750
So...
01:02:10.750 --> 01:02:24.630
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.
01:02:25.309 --> 01:02:30.250
It does not necessarily say which features are involved in that.
01:02:30.250 --> 01:02:39.730
It just defines a communication protocol and that certain functions are either living on the wayside or on the onboard.
01:02:39.889 --> 01:02:41.210
That's this allocation thing.
01:02:41.789 --> 01:02:48.130
If you look at ETCS, for example, you've got, I don't know, say 10,000 features of ETCS.
01:02:48.690 --> 01:02:52.789
And if a railway only wants to use five of them, that's perfectly okay.
01:02:53.150 --> 01:03:03.829
But you still have an interface specification between wayside and onboard that would allow you to transmit communication for all 10,000 features.
01:03:04.309 --> 01:03:09.849
Regardless of whether you only take five of them or 150 or 3,000, it doesn't matter.
01:03:10.610 --> 01:03:13.409
The interface specification always stands.
01:03:13.530 --> 01:03:14.610
The protocol is there.
01:03:14.909 --> 01:03:15.989
The language is there.
01:03:16.670 --> 01:03:20.969
And on that basis, you could introduce additional innovations in the future.
01:03:21.730 --> 01:03:32.429
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.
01:03:33.150 --> 01:03:34.050
That's all there is.
01:03:34.289 --> 01:03:44.170
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.
01:03:44.570 --> 01:03:48.070
What the onboard does with it doesn't matter.
01:03:48.489 --> 01:03:52.210
How the wayside gets to the commands doesn't matter.
01:03:52.730 --> 01:03:54.929
And every supplier can do this in a different way.
01:03:54.929 --> 01:04:03.429
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.
01:04:05.559 --> 01:04:14.840
Yeah, again, looking at the New York I2S specs, it's not just one interface that's captured in there in their specifications.
01:04:15.119 --> 01:04:21.619
There's maybe 10 or 12 interfaces that are captured in their specifications because of the functionality.
01:04:23.380 --> 01:04:33.820
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.
01:04:34.099 --> 01:04:34.880
Yes, yes.
01:04:35.019 --> 01:04:36.219
So these are the intricacies.
01:04:36.460 --> 01:04:48.280
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.
01:04:48.519 --> 01:04:49.960
So yeah, that's right.
01:04:50.019 --> 01:04:50.559
That's understood.
01:04:50.559 --> 01:04:59.000
But the main aspect of interoperability is really the train not being able to communicate with the wayside.
01:04:59.159 --> 01:05:05.800
So the train to wayside interface is really the most critical one that needs to be addressed in interoperability.
01:05:06.639 --> 01:05:24.900
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.
01:05:25.179 --> 01:05:26.579
So there's the little plug for that.
01:05:27.260 --> 01:05:43.219
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?
01:05:44.619 --> 01:05:57.219
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.
01:05:57.380 --> 01:05:57.980
Yeah, yeah.
01:05:58.159 --> 01:06:00.159
And I'm happy for them to do that.
01:06:00.280 --> 01:06:02.800
And I'll tweak it a little bit.
01:06:02.940 --> 01:06:13.699
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.
01:06:14.099 --> 01:06:24.940
So yeah, I think maybe just to summarise, I think the very fact that this topic is getting aired in the industry is good.
01:06:27.739 --> 01:06:37.239
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.
01:06:37.239 --> 01:06:40.280
You know, this is all beneficial.
01:06:41.079 --> 01:06:45.760
It's all moves, hopefully moves the industry forward in a positive way.
01:06:45.860 --> 01:06:50.460
Yes, and if it doesn't, then at least they do so with open eyes.
01:06:50.619 --> 01:07:01.780
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.
01:07:01.860 --> 01:07:12.019
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.
01:07:12.699 --> 01:07:14.980
And that works as long as it works.
01:07:15.579 --> 01:07:23.000
And then if parts of the market are getting steamrolled by an interoperable Chinese solution, then so be it.
01:07:23.599 --> 01:07:27.099
Maybe some suppliers say, now we want to do this differently.
01:07:27.440 --> 01:07:38.619
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.
01:07:39.039 --> 01:07:54.039
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.
01:07:55.139 --> 01:08:04.500
I don't know, but it opens all kinds of interesting angles on this discussion, which I think is generally good for the industry.
01:08:05.260 --> 01:08:11.579
And it just creates clarity where people can see with open eyes, okay, well, this is what I'm doing.
01:08:11.719 --> 01:08:12.800
This is what I'm not doing.
01:08:12.920 --> 01:08:14.099
And here's the reason why.
01:08:14.619 --> 01:08:20.000
So I can't say I didn't know any other way because you and I have written these papers.
01:08:20.199 --> 01:08:21.300
So it's out in the public.
01:08:21.659 --> 01:08:24.500
There is another way, or there may be more than one way.
01:08:24.939 --> 01:08:27.800
And then they can make a decision with open eyes.
01:08:27.899 --> 01:08:28.779
Am I going this way?
01:08:28.859 --> 01:08:29.859
Am I going that way?
01:08:29.859 --> 01:08:32.840
And I think this is what good consultancy is for.
01:08:33.800 --> 01:08:41.140
And also what thought leadership is for, which I think we're currently practicing to some degree with that discussion.
01:08:42.239 --> 01:08:50.460
And yeah, and I hope that this conversation here was interesting for the readers as much as the upcoming papers will be interesting.
01:08:51.260 --> 01:08:54.779
And I'd like to thank you for your contribution.
01:08:54.939 --> 01:08:58.359
I always like talking to you very, very much.
01:08:58.359 --> 01:09:00.779
And I hope that wasn't the last one.
01:09:00.939 --> 01:09:10.060
And I'm pretty sure we will find lots of other topics regarding to CBTC and the wider railways that are very, very interesting.
01:09:10.239 --> 01:09:14.079
I know that the topic of innovation is very close to your heart.
01:09:14.260 --> 01:09:27.680
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.
01:09:27.680 --> 01:09:31.579
And deployed into real products, which is a bit of a shame.
01:09:32.119 --> 01:09:36.260
So there will be some headway for the future for further innovations.
01:09:36.539 --> 01:09:40.100
And maybe we can pick up that discussion another time.
01:09:41.840 --> 01:09:42.359
Okay.
01:09:43.380 --> 01:09:44.600
My pleasure, Frank.
01:09:44.680 --> 01:09:47.859
It's been great talking to you and really, really good discussions.
01:09:47.899 --> 01:09:50.479
So thank you very much for the invitation.
01:09:53.239 --> 01:09:54.760
Hi, it's Doc Frank again.
01:09:54.899 --> 01:09:57.000
I hope you enjoyed this conversation.
01:09:57.810 --> 01:10:07.359
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.
01:10:07.539 --> 01:10:16.420
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.
01:10:16.819 --> 01:10:37.140
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.
01:10:37.939 --> 01:10:40.079
With that said, thank you very much.
01:10:40.279 --> 01:10:41.699
Hope to see you again soon.
01:10:42.119 --> 01:10:43.479
And bye for now.