News   Dec 23, 2025
 728     3 
News   Dec 23, 2025
 1.8K     1 
News   Dec 23, 2025
 2.6K     1 

GO Transit: Service thread (including extensions)

Can I point out one thing about ETCS.....

It was the best system 10 years ago. It may not be the best system tomorrow.

Let's not focus on one sole technology for technology's sake. They reason why they are going to test on the Richmond Hill Line is because it is isolated, and will help guide the installation on future corridors - but it may also show that it can not work in the North American environment. Metroilnx may have settled on ETCS for now, but that is certainly not the only option that they have looked at, , going all the way to full-blown CBTC setups as well.

Dan
ETCS is not a "system" per se. Nor is it a particular technology. It's more like a set of standards. I'd say it's a signal system architecture, but even that's not really true, since the different ETCS Levels have significantly different architecture. ETCS can be anything from a rudimentary block system on a rural branch line with axle counters, to a fully communications-based system with moving blocks, comparable to CBTC.

As far as I'm aware, communications-based moving-block signalling systems are the pinnacle of current signal technology, so it's not reasonable to imply that ETCS is obsolete. I'm not even sure it's possible for ETCS to become obsolete, because it's constantly being developed. One exciting recent development is virtual micro-blocks, which provide the performance of a moving block system while making it much more practical to overlay physical blocks for non-equipped freight trains. The Netherlands developed that capability within the past decade and it was incorporated in to ETCS Level 2 Baseline 3 in 2023. Whenever there's a new innovation in signal technology, it can either be incorporated into existing ETCS architectures by swapping out the relevant components (thanks to the standardized communications protocols between components) or if necessary they can create a new ETCS Level to incorporate that technology.

When Metrolinx says "We are implementing ETCS", it means they are signing on to the world's most common set of standards for railway signalling communications, rather than locking themselves in to a proprietary system like the TTC did with CBTC on the Finch West LRT (Thales) and Eglinton LRT (Bombardier/Alstom). It's impossible to run a Finch LRT train on the Eglinton LRT due to incompatible CBTC systems, even though the lines would otherwise be compatible with each other (same loading gauge, platform height, electrification etc). New York has done some good work to enable intercompatibility between CBTC systems, but their work is not easily applicable to mainline railway applications (especially with non-equipped freight trains sharing the line).

PTC is another option sometimes suggested for Metrolinx, but it's little more than a set of performance requirements for Automatic Train Protection in the US, while ETCS is a full set of signal standards used around the world. PTC generally tacks onto traditional North American signal systems, which are much more expensive to implement with the super-tight blocks we need for GO Expansion service levels. The traditional North American systems also create unnecssarily high task saturation for train operators when there are very short blocks.

We're not implementing ETCS Level 2 because it's cool to have new technology, we're implementing it because ETCS L2 is specifically very well suited for situations like GO Expansion: high-frequency passenger train operation on a line shared with freight trains, with differing levels of signalling equipment aboard a variety of different train types from different operators. Metrolinx has stated that they plan to adopt the ETCS standard, and I don't see any reason to doubt that, nor suggest that they should do otherwise.
 
Last edited:
ETCS is not a "system" per se. Nor is it a particular technology. It's more like a set of standards. I'd say it's a signal system architecture, but even that's not really true, since the different ETCS Levels have significantly different architecture. ETCS can be anything from a rudimentary block system on a rural branch line with axle counters, to a fully communications-based system with moving blocks, comparable to CBTC.

As far as I'm aware, communications-based moving-block signalling systems are the pinnacle of current signal technology, so it's not reasonable to imply that ETCS is obsolete. I'm not even sure it's possible for ETCS to become obsolete, because it's constantly being developed. One exciting recent development is virtual micro-blocks, which provide the performance of a moving block system while making it much more practical to overlay physical blocks for non-equipped freight trains. The Netherlands developed that capability within the past decade and it was incorporated in to ETCS Level 2 Baseline 3 in 2023. Whenever there's a new innovation in signal technology, it can either be incorporated into existing ETCS architectures by swapping out the relevant components (thanks to the standardized communications protocols between components) or if necessary they can create a new ETCS Level to incorporate that technology.

When Metrolinx says "We are implementing ETCS", it means they are signing on to the world's most common set of standards for railway signalling communications, rather than locking themselves in to a proprietary system like the TTC did with CBTC on the Finch West LRT (Thales) and Eglinton LRT (Bombardier/Alstom). It's impossible to run a Finch LRT train on the Eglinton LRT due to incompatible CBTC systems, even though the lines would otherwise be compatible with each other (same loading gauge, platform height, electrification etc). New York has done some good work to enable intercompatibility between CBTC systems, but their work is not easily applicable to mainline railway applications (especially with non-equipped freight trains sharing the line).

PTC is another option sometimes suggested for Metrolinx, but it's little more than a set of performance requirements for Automatic Train Protection in the US, while ETCS is a full set of signal standards used around the world. PTC generally tacks onto traditional North American signal systems, which are much more expensive to implement with the super-tight blocks we need for GO Expansion service levels. The traditional North American systems also create unnecssarily high task saturation for train operators when there are very short blocks. We're not implementing ETCS Level 2 because it's cool to have new technology, we're implementing it because ETCS L2 is specifically very well suited for situations like GO Expansion: high-frequency passenger train operation on a line shared with freight trains, with differing levels of signalling equipment aboard a variety of different train types from different operators.

Metrolinx has already stated that they plan to adopt the ETCS standard, and I don't see any reason to doubt that, nor suggest that they should do otherwise.
Then you must also be aware then that it uses an antiquated radio frequency spectrum that can not be used in North America and who's existence in Europe is tied solely to its use as part of the ETCS standards, and for which there is a rush to try and design and register a replacement as its end date is fast approaching.

Not to mention the fact that none of the hardware approved to be used with ETCS has been tested to work on or around 60Hz power grids.

Don't get me wrong, it's good. There's a reason why most of Europe is now using it, not to mention a handful of other locations in the world. But it's also an unknown quantity here because of the peculiarities of life in North America.

Dan
 
As I think WB62 said another time, i think MX is just really bad at pdf schedule releases for some reason.
Transsee/GTFS still says 4/day on Jan 10th

It doesn't make sense for a singular train Union -> KI in evening.

View attachment 705659

More on this topic in case it's of interest:

1767040854118.png
 
More on this topic in case it's of interest:

View attachment 705685

I think the social media representative is confusing the January schedule change with the December schedule change that’s currently in effect, because the January schedule does maintain 30 minute service between Union Station and Bramalea GO 7 days a week:

IMG_7771.jpeg


This whole situation is ridiculous, and shows how poorly Metrolinx coms can be. This is a mistake thats been present for over 2 weeks despite people sending in notices
 
Then you must also be aware then that it uses an antiquated radio frequency spectrum that can not be used in North America and who's existence in Europe is tied solely to its use as part of the ETCS standards, and for which there is a rush to try and design and register a replacement as its end date is fast approaching.

Not to mention the fact that none of the hardware approved to be used with ETCS has been tested to work on or around 60Hz power grids.

Don't get me wrong, it's good. There's a reason why most of Europe is now using it, not to mention a handful of other locations in the world. But it's also an unknown quantity here because of the peculiarities of life in North America.

Dan
This is not an ETCS problem. ERTMS, ETCS and GSM-R are not interchangeable or equivalent! The ERTMS project has three pillars: railway mobile radio (RMR), the European Train Control System (ETCS), and the European Traffic Management Layer (ETML). ETCS itself does not imply a specific RMR technology (anymore): they are entirely separate pillars.

You're correct that many ETCS Level 2 deployments rely on GSM-R for communication between trains and the radio block centre (RBC). You're also correct that GSM-R is approaching end-of-life (though it has nothing to do with the spectrum itself as you suggest -- telcos would pay billions for that spectrum). Most European deployments use GSM-R because GSM-R is mandated in EU law through the Command, Control & Signalling Technical Specifications for Interoperability (CCS TSI).

But there are many more ETCS deployments in India, Mexico, South Korea, Kazakhstan, Finland, etc. that don't use GSM-R. The beauty of ETCS is that it doesn't care what the communications medium is: GSM-R, LTE, 5G, satellite, smoke signal, carrier pigeon, etc. This bearer independence has only been strengthened through the Future Railway Mobile Communications System (FRMCS) project led by the UIC.

Yes, the European rail sector was caught flat-footed by the belief that GSM-R could be made to work forever. Yes, the CCS TSI will be updated to require FRMCS. And yes, European countries subject to the CCS TSI will be required to deploy 5G-based FRMCS networks. Fortunately, we are not subject to the EU rules. (Which is great, because I cannot see ISED ever gifting the rail industry 5 or 10 MHz of "good" spectrum like CEPT did -- there are enough issues with that in Australia, among other jurisdictions.)

All of the above notwithstanding, we can talk about ETCS in Canada without comms network whataboutism. I agree that there are many unknowns around ETCS deployment in Canada, and I'd rather spend time solving those problems than inventing new ones. For example, how will we get buy-in for a culture shift to 21st century operating practices that ETCS was designed around? How will ETCS equipment operate on foreign railroads: STM, or dual fitment of onboard or wayside? Will we be able to build on worldwide assurance work, or do we have to re-do all the assurance from nothing?

The comms network is the easy part.
 
This is not an ETCS problem. ERTMS, ETCS and GSM-R are not interchangeable or equivalent! The ERTMS project has three pillars: railway mobile radio (RMR), the European Train Control System (ETCS), and the European Traffic Management Layer (ETML). ETCS itself does not imply a specific RMR technology (anymore): they are entirely separate pillars.

You're correct that many ETCS Level 2 deployments rely on GSM-R for communication between trains and the radio block centre (RBC). You're also correct that GSM-R is approaching end-of-life (though it has nothing to do with the spectrum itself as you suggest -- telcos would pay billions for that spectrum). Most European deployments use GSM-R because GSM-R is mandated in EU law through the Command, Control & Signalling Technical Specifications for Interoperability (CCS TSI).

But there are many more ETCS deployments in India, Mexico, South Korea, Kazakhstan, Finland, etc. that don't use GSM-R. The beauty of ETCS is that it doesn't care what the communications medium is: GSM-R, LTE, 5G, satellite, smoke signal, carrier pigeon, etc. This bearer independence has only been strengthened through the Future Railway Mobile Communications System (FRMCS) project led by the UIC.

Yes, the European rail sector was caught flat-footed by the belief that GSM-R could be made to work forever. Yes, the CCS TSI will be updated to require FRMCS. And yes, European countries subject to the CCS TSI will be required to deploy 5G-based FRMCS networks. Fortunately, we are not subject to the EU rules. (Which is great, because I cannot see ISED ever gifting the rail industry 5 or 10 MHz of "good" spectrum like CEPT did -- there are enough issues with that in Australia, among other jurisdictions.)

All of the above notwithstanding, we can talk about ETCS in Canada without comms network whataboutism. I agree that there are many unknowns around ETCS deployment in Canada, and I'd rather spend time solving those problems than inventing new ones. For example, how will we get buy-in for a culture shift to 21st century operating practices that ETCS was designed around? How will ETCS equipment operate on foreign railroads: STM, or dual fitment of onboard or wayside? Will we be able to build on worldwide assurance work, or do we have to re-do all the assurance from nothing?

The comms network is the easy part.
That GSM-R has been not made to be a requirement anymore is a good thing. A friend of mine works in the industry, and while he has had very little experience with ETCS and ERTMS, his understanding was that the use of GSM-R was a requirement - perhaps that was an earlier iteration of the system? It's good to hear that it's more flexible than that.

Dan
 
The missing weekend trips to Kitchener were luckily just a copy/paste error in the PDF, but the Lakeshore East and West service cuts seem to be real. We're 4 days from the next schedule change and the only Lakeshore timetables are the ones effective December 20th with service slashed to 1 train per hour. A far cry from the 15-minute service we had in the summer.
Capture2.PNG


If this is true, the Kitchener line will have more frequent service than the Lakeshore line for the first time ever. Partly due to impressive service increases on Kitchener, but mostly due to brutal cuts to Lakeshore.
 
Last edited:
The missing weekend trips to Kitchener were luckily just a copy/paste error in the PDF, but the Lakeshore East and West service cuts seem to be real. We're 4 days from the next schedule change and the only Lakeshore timetables are the ones effective December 20th with service slashed to 1 train per hour. A far cry from the 15-minute service we had in the summer.
View attachment 705929

If this is true, the Kitchener line will have more frequent service than the Lakeshore line for the first time ever. Partly due to impressive service increases on Kitchener, but mostly due to brutal cuts to Lakeshore.

I checked the TransitApp departures for January 3rd onwards, and all I’ve been able to notice was a fully restored schedule. Obviously I could be wrong, but I don’t think the new January schedules for LE/LW have been published yet.
 
I checked the TransitApp departures for January 3rd onwards, and all I’ve been able to notice was a fully restored schedule. Obviously I could be wrong, but I don’t think the new January schedules for LE/LW have been published yet.
Ah thanks for that. I guess I'll just wait for the updated PDFs to come out before making this year's regional rail summary.
 
All of the above notwithstanding, we can talk about ETCS in Canada without comms network whataboutism. I agree that there are many unknowns around ETCS deployment in Canada, and I'd rather spend time solving those problems than inventing new ones. For example, how will we get buy-in for a culture shift to 21st century operating practices that ETCS was designed around? How will ETCS equipment operate on foreign railroads: STM, or dual fitment of onboard or wayside? Will we be able to build on worldwide assurance work, or do we have to re-do all the assurance from nothing?

The comms network is the easy part.

When I was across the pond a few months back, I watched an EMU set pull into a stub end platform at a large city terminal and unload. Almost immediately a second EMU set pulled into the same track, stopped a few feet short of the first trainset, coupled on, and then unloaded its passengers as well. And then, the combined trainset immediately prepared to depart as an outbound train.. All accomplished as loaded trains with just a few hand signals between two operators, one on each train, in less than two minutes..

The signalling system enables some of this process, but the entire set of operating rules is completely different from - and in many ways violates core principles of - traditional North American operating rules. Putting two trains on the same platform at Union Station - let alone coupling them together - is a much more complicated procedure, and is discouraged by past operating experience as well as the characteristics of the trains themselves..

It's easy (relatively) to impose a different operating regime on a captive island system like say TTC subway.....but moving away from CROR, especially where it will continue to apply where GO trains cross into other railroad territory - will probably take as much work and persuasion as designing the signalling system itself. And the operating rules define how the signslling must work, so the two must be designed concurrently. One has to think that ML has an inkling of what the new operating environment will look like - it's one reason why so much foreign talent has been imported.

A very major change initiative, and well beyond just picking the hardware and software.

- Paul
 
Last edited:
The signalling system enables some of this process, but the entire set of operating rules is completely different from - and in many ways violates core principles of - traditional North American operating rules. Putting two trains on the same platform at Union Station - let alone coupling them together - is a much more complicated procedure, and is discouraged by past operating experience as well as the characteristics of the trains themselves..

It's easy (relatively) to impose a different operating regime on a captive island system like say TTC subway.....but moving away from CROR, especially where it will continue to apply where GO trains cross into other railroad territory - will probably take as much work and persuasion as designing the signalling system itself. And the operating rules define how the signslling must work, so the two must be designed concurrently. One has to think that ML has an inkling of what the new operating environment will look like - it's one reason why so much foreign talent has been imported.

A very major change initiative, and well beyond just picking the hardware and software.

- Paul
Yes exactly, and that's why I've been emphasizing that we need to make noise about changing GO Transit and Transport Canada policies to make it possible to operate railways efficiently as they do in Europe and Asia. Clearly the CROR is not the only way to operate railways safely given that the EU achieves equal or better railway safety than Canada.

If left to their own devices, GO Transit and Transport Canada will demand that ETCS be mutilated to conform to the antiquated North American operating policies, eliminating many of ETCS's benefits, increasing its implementation cost, increasing the cost of operating service in general (e.g. lower capacity, potentially 2 operators per cab), and increasing the potential for new issues to be created as a result of their modifications. Deutsche Bahn was trying to push GO Transit to modernise their operating practices and we know how that turned out...
 
If left to their own devices, GO Transit and Transport Canada will demand that ETCS be mutilated to conform to the antiquated North American operating policies, eliminating many of ETCS's benefits, increasing its implementation cost, increasing the cost of operating service in general (e.g. lower capacity, potentially 2 operators per cab), and increasing the potential for new issues to be created as a result of their modifications. Deutsche Bahn was trying to push GO Transit to modernise their operating practices and we know how that turned out...

All quite true, but I'm willing to give ML a bit of slack here. I suspect they understand the need for change and would like to see someone make those changes for them - however, they may or may not have the internal expertise to make that case on their own.

I have a feeling that the situation with DB may have been more complex, in that DB was effectively a vendor whose pricing may have been set in the belief that they could change practices quickly and reap the benefits without any fuss. The cold water on the relationship may have been the discovery that the regulator is stuck in CROR culture, and a very long and detailed selling job is needed before new practices can be applied.... and the pricing they offered may have underbid what the costs will be for the next decade.

And a further problem being, the CROR is aligned to the equipment and technologies ML runs today, and it may actually demand new equipment to follow new rules. One might have to eliminate Westinghouse air brakes, Janney couplers, and control of locomotives from 12 cars away under typical North American connectivity and slack considerations, in order to operate GO trains to the European practices)

- Paul
 

Back
Top