ASFA or AWS: Which would be better?

[Broken Viking]

Hi everyone!
Ever since I learned about it five years ago - Even seeing it in operation first hand - I've become firmly convinced that Anuncio de Señales y Frenado Automático (ASFA; Spanish for Signal Advisory and Automatic Braking System (SAABS)) is absolutely superior to AWS. Unlike AWS which employs a single General acknowledge plunger (And associated muscle memory habits) ASFA actively tests for driver attention and correct response by obliging different responses to different conditions, as well as presenting live checks on driver awareness by occasionally presenting one aspect more restrictive than what is necessary (e.g: Anuncio Parada/Single amber where the signalling system is allowing Precaution) and clearing to the correct less restrictive aspect if the driver responds appropriately to the more restrictive aspect on approach. ASFA Digital also improves driver awareness by giving advance notice of certain conditions e.g. Señales successivas en Anuncio de Parada (Successive signals in "Prepare to Stop" aspect) allowing for near TVM-like levels of advance perception and planning.

Technologically, ASFA - Like AWS - Is balaise based, and two are provided for each signal - One at the signal, and one typically about 300m in advance which primes the on-train ASFA equipment with the aspect being displayed. Information is communicated by specific radio frequencies, but I believe (Like in AWS) there's also a fixed magnet which allows the equipment to detect a balaise that's present but unpowered, I assume being taken to be Error (Parada/Danger assumed) in such cases. Theoretically speaking ASFA could even be implemented on road vehicles as well as rail, with the RF-based signalling meaning less precision being obliged between the balaise and the vehicle passing over it.

Granted and in fairness, AWS - Evolved from a GWR system introduced around 1948 - Came along about 40 years before ASFA Basicó (Late 1980s) but hasn't received the same modernisations and expansion of functionality that came along with ASFA Digital. Theoretically ASFA could be provisioned as a drop-in upgrade for AWS that would eliminate many overrun/SPAD incidents (I place heavy emphasis on the theoretical there! ) but would be an implementation headache for those accustomed to working under AWS and having to change to acknowledging precise aspects via three new buttons on the control desk.

I'm curious to learn what others think of ASFA in comparison to AWS. Had the UK developed things differently and not "grandfathered" AWS into the network, might we have bought ASFA in as a phased upgrade and so be employing it here today?

 

[Tetragon213]

I think Southern Region/Signalling Repeating AWS would have been more likely to have been implemented over an overseas system ("not invented here" syndrome strikes again!)

 

[hexagon789]

AFSA sounds a little like SRAWS, Signal Repeating AWS which the BR Southern Region trialled on the Bournemouth Line in the 70s-early 80s before the decision was taken to fit standard AWS across the Southern Region. It too required acknowledgement of the correct signal indication if it wasn't green.

A small point about one part of your post, AWS doesn't seek to prevent SPADs per se that's more the function of TPWS, though even TPWS seeks more to reduce the seriousness of a SPAD by stopping a train before the conflict point within the overlap.

== Doublepost prevention - post automatically merged: 4 Jun 2025 ==

I think Southern Region/Signalling Repeating AWS would have been more likely to have been implemented over an overseas system ("not invented here" syndrome strikes again!)

We must've been thinking exactly the same thing at the same time!

 

[Broken Viking]

AFSA sounds a little like SRAWS, Signal Repeating AWS.

Oooh, I wasn't aware of SRAWS! I'll have to read up on that! Really surprised to see BR not choosing the safety-positive ASFA-like option!

And looking at that early 80s date - In tandem with the awareness Spain was in an extremely disadvantaged position around that time and would have been heavily reliant on cheaper options - I wonder if SRAWS technology might have been sold to ReNFE at a discount for BR not really wanting it, and that being further developed to create ASFA?

If that turns out to be the foundations of ASFA, it also means the common technological basis might actually make ASFA implementation in the UK a literal drop-in process!

A small point about one part of your post, AWS doesn't seek to prevent SPADs per se that's more the function of TPWS, though even TPWS seeks more to reduce the seriousness of a SPAD by stopping a train before the conflict point within the overlap.

One thing about ASFA is that it can intervene further ahead of a crisis e.g. by stopping a train that passes a signal at Precaution in overspeed and/or without acknowledgement because the driver has lost capability. Under AWS the same circumstance might not be checked until the next single amber, by which point the train might already be at significant speed and less likely to stop short of danger further up the line. (Putting aside the DSD kicking in well before that point, we hope!)

I think Southern Region/Signalling Repeating AWS would have been more likely to have been implemented over an overseas system ("not invented here" syndrome strikes again!)

I personally detest that latter sort of mindset. Could you imagine trying to operate HS1 on colour light signalling because TVM/ECTS-1 was a French invention?!?

Sometimes, using overseas developed solutions is faster, cheaper and better than trying to develop your own equivalents without learned experience. The large collection of UK-made ground frames and interlockings employed on large parts of the Spanish network and now on display at the Museo de los Ferrocarriles in Madrid proves that the Spanish learned this lesson years ago...And look at which of the two countries now has a positive-response signalling system, and Velaros which don't suffer from the Güt und Günstige problem which Eurostar cursed theirs with!

 

[Annetts key]

Hi everyone!
Ever since I learned about it five years ago - Even seeing it in operation first hand - I've become firmly convinced that Anuncio de Señales y Frenado Automático (ASFA; Spanish for Signal Advisory and Automatic Braking System (SAABS)) is absolutely superior to AWS. Unlike AWS which employs a single General acknowledge plunger (And associated muscle memory habits) ASFA actively tests for driver attention and correct response by obliging different responses to different conditions, as well as presenting live checks on driver awareness by occasionally presenting one aspect more restrictive than what is necessary (e.g: Anuncio Parada/Single amber where the signalling system is allowing Precaution) and clearing to the correct less restrictive aspect if the driver responds appropriately to the more restrictive aspect on approach. ASFA Digital also improves driver awareness by giving advance notice of certain conditions e.g. Señales successivas en Anuncio de Parada (Successive signals in "Prepare to Stop" aspect) allowing for near TVM-like levels of advance perception and planning.

Technologically, ASFA - Like AWS - Is balaise based, and two are provided for each signal - One at the signal, and one typically about 300m in advance which primes the on-train ASFA equipment with the aspect being displayed. Information is communicated by specific radio frequencies, but I believe (Like in AWS) there's also a fixed magnet which allows the equipment to detect a balaise that's present but unpowered, I assume being taken to be Error (Parada/Danger assumed) in such cases. Theoretically speaking ASFA could even be implemented on road vehicles as well as rail, with the RF-based signalling meaning less precision being obliged between the balaise and the vehicle passing over it.

Granted and in fairness, AWS - Evolved from a GWR system introduced around 1948 - Came along about 40 years before ASFA Basicó (Late 1980s) but hasn't received the same modernisations and expansion of functionality that came along with ASFA Digital. Theoretically ASFA could be provisioned as a drop-in upgrade for AWS that would eliminate many overrun/SPAD incidents (I place heavy emphasis on the theoretical there! ) but would be an implementation headache for those accustomed to working under AWS and having to change to acknowledging precise aspects via three new buttons on the control desk.

I'm curious to learn what others think of ASFA in comparison to AWS. Had the UK developed things differently and not "grandfathered" AWS into the network, might we have bought ASFA in as a phased upgrade and so be employing it here today?

Yes, widespread fitment of AWS came about because the safety benefits of the GWR ATC (Automatic Train Control) system could be seen after an investigation into an accident. ATC not being suitable for use on third rail lines.

AWS is specifically a warning system, not a control system as far as the British railways are concerned. The primary purpose is to warn drivers of a restrictive aspect (originally a distant signal at caution).

AWS is not balaise based. AWS uses permanent magnets and electro-magnets mounted in the middle of the track.

Extensions and enhancements to AWS had been looked at. But were never developed further. Two pilot ATP (Automatic Train Protection) systems were fitted as a result of the inquiry recommendations of the Clapham Junction rail crash. But these were not extended because the government decided the cost of nationwide fitment was too high. Both are based on systems adapted from other countries.

TPWS (Train Protection & Warning System) was instead developed. And has been fitted to all trains and at all "at risk" signals, but not to every signal.

The type of balaise used on British railways gets power from a transmitter on the train. These are used so that fitted trains know where the length of certain platforms ends, so that trains know where the OHL ends as well as being used for ERTMS/ETCS. ERTMS/ETCS being the intended system that is now being fitted (although rather slowly).

Meanwhile, the ATP on the Great Western main lines between Bristol Temple Meads and London Paddington and between Bristol Parkway and Swindon (where the two main lines merge) is still operational and in use.

Given the resistance to ATP and the lowest possible cost that TPWS was suppose to be for fitting on trains, I don't think ASFA would have been considered.

 

[MarkyT]

Don't forget AWS was supplemented by TPWS in the early 2000s at the riskiest locations. The new system adds overspeed and trainstop functions. Suppliers developed drop-in modules to replace previous AWS only equipment on older traction to enable the new functionality. They used the same traction and braking interface for ease of installation. ASFA seems to be very similar to German Indusi or PZB, and includes advance warning, overspeed and trainstop frequencies that are passively switched and interrogated by a powered transducer on the train. ASFA and PZB offer better protection than systems in the UK today, no doubt, as does French KVB and other national systems, many of which have been converted to use digital Eurobalises for message transfer rather than inductive code frequencies. It wouldn't be economic to switch over wholesale to another deadend legacy system. A halfway house might be a custom limited supervision sub-level 1 system based on AWS/TPWS and emulated using Eurobalises. Most of the continent is gravitating towards just such a system on many lines, alongside radio-based Level 2 on the busiest and fastest lines. They can be emulated by standard modern ETCS-equipped traction, using a standard balise reader instead of additional antennas, and assuming the unit has the correct emulation software.

 

[HSTEd]

Don't forget AWS was supplemented by TPWS in the early 2000s at the riskiest locations. The new system adds overspeed and trainstop functions. Suppliers developed drop-in modules to replace previous AWS only equipment on older traction to enable the new functionality. They used the same traction and braking interface for ease of installation. ASFA seems to be very similar to German Indusi or PZB, and includes advance warning, overspeed and trainstop frequencies that are passively switched and interrogated by a powered transducer on the train. ASFA and PZB offer better protection than systems in the UK today, no doubt, as does French KVB and other national systems, many of which have been converted to use digital Eurobalises for message transfer rather than inductive code frequencies. It wouldn't be economic to switch over wholesale to another deadend legacy system. A halfway house might be a custom limited supervision sub-level 1 system based on AWS/TPWS and emulated using Eurobalises. Most of the continent is gravitating towards just such a system on many lines, alongside radio-based Level 2 on the busiest and fastest lines. They can be emulated by standard modern ETCS-equipped traction, using a standard balise reader instead of additional antennas, and assuming the unit has the correct emulation software.

Adoption of ETCS L1LS would also let us remove a whole bunch of AWS hardware, because bidirectional installations would no longer require suppression in the reverse direction. ETCS messages are natively direction specific after all.

I think an expedited conversion to L1LS is probably a reasonable effort given how slowly the full fat ETCS is moving.
We can get a whole bunch of new capabilities and reduce the lineside powered equipment substantially.

But seems to be little point doing anything that is not ETCS based now.

 

[zwk500]

Adoption of ETCS L1LS would also let us remove a whole bunch of AWS hardware, because bidirectional installations would no longer require suppression in the reverse direction. ETCS messages are natively direction specific after all.

I think an expedited conversion to L1LS is probably a reasonable effort given how slowly the full fat ETCS is moving.
We can get a whole bunch of new capabilities and reduce the lineside powered equipment substantially.

But seems to be little point doing anything that is not ETCS based now.

One of the biggest benefits of ETCS L2 is on bi-di lines, and if you've got continuous train detection and ETCS fitted stock the value of installing ETCS L1-LS against L2 is pretty minimal. ETCS L1 still requires signals, so all the proving and connections for that as well as (significantly) the structures for sighting signals on wrong direction lines. L2 just needs a block marker board by the side of the track so that the driver knows the limit of the MA

ETCS L1-LS would be of greater benefit if some method of proving the train was complete without continuous detection was part of the ETCS standards. An EOT device linked to the MA with a Balise reader would be an obvious solution, but it could even be a tail lamp CCTV camera if it had a suitable field of view, while MU trains presumably already have some kind of linking between the sets to enable the emergency braking applications.

 

[HSTEd]

One of the biggest benefits of ETCS L2 is on bi-di lines, and if you've got continuous train detection and ETCS fitted stock the value of installing ETCS L1-LS against L2 is pretty minimal. ETCS L1 still requires signals, so all the proving and connections for that as well as (significantly) the structures for sighting signals on wrong direction lines. L2 just needs a block marker board by the side of the track so that the driver knows the limit of the MA

ETCS L1LS can use the equipment that is already present, with drop in replacements for existing AWS or TPWS devices providing the same or more functionality, whilst the signalling remains iun place.
ETCS L2 will almost always require a complete resignalling to implement (trying to backfit it into a relay interlocking sounds like a fun exercise!).

Given the ongoing and worsening crisis in the signalling sector, resignalling is going to have to wait an awful long time.

Conversion to L1LS would allow us to be rid of the burden of AWS and TPWS (along with the vestigal GWML ATP system), and deal with emergent risks such as the recent ECML acceleration incidents.

ETCS L1-LS would be of greater benefit if some method of proving the train was complete without continuous detection was part of the ETCS standards. An EOT device linked to the MA with a Balise reader would be an obvious solution, but it could even be a tail lamp CCTV camera if it had a suitable field of view, while MU trains presumably already have some kind of linking between the sets to enable the emergency braking applications.

And this is where I once again shill for my favoured train integrity technology! Electronically controlled pneumatic braking!

Little point inventing a new solution when an operationally proven solution already exists, which can also have other benefits such as making expensive hotbox detectors redundant.

 

[zwk500]

ETCS L1LS can use the equipment that is already present, with drop in replacements for existing AWS or TPWS devices providing the same or more functionality, whilst the signalling remains iun place.
ETCS L2 will almost always require a complete resignalling to implement (trying to backfit it into a relay interlocking sounds like a fun exercise!).

Given the ongoing and worsening crisis in the signalling sector, resignalling is going to have to wait an awful long time.

Conversion to L1LS would allow us to be rid of the burden of AWS and TPWS (along with the vestigal GWML ATP system), and deal with emergent risks such as the recent ECML acceleration incidents.

Fair Points

And this is where I once again shill for my favoured train integrity technology! Electronically controlled pneumatic braking!

Little point inventing a new solution when an operationally proven solution already exists, which can also have other benefits such as making expensive hotbox detectors redundant.

I certainly agree ECP braking should be fitted in much of the wagon fleet, but it won't cover every eventuality, so *something* else will be needed. Formations with vehicles dead-in-tow, heritage stock, faults, etc,

Also, if ECP braking is to work with undetected sections, it will need some method of exchanging a 'train complete' data packet with a Balise Group, and that some kind of 'train complete' slot/control to be integrated with the interlocking. And if you have that setup, then also having the option of sticking and EOT device that is linked to the loco and can also exchange the data packet is a separate thing from ECP braking and would be useful in it's own regard, as well as offering a degraded working state for ECP fitted stock.

 

[MarkyT]

ECP, while it can detect and react to a train split very quickly, doesn't inherently report length information, which is vital to determine the moment when the rear of a train clears a train detection section, to release junction locking for conflicting moves perhaps. An EOT balise reader 'paired' with a head unit, could plausibly determine very accurately when the tail has passed a particular balise previously passed by the head reader.

Digital ECP systems can bring many benefits including smoother more controlled braking, data channels for diagnostics both for the brake system and other important indications such as axle bearing temperatures, but to provide a cast-iron SIL 4 decision to release locking and allow a point to move I'd like to measure each time, which an EOT reader could provide. Even then I'd also have deadlocking axle counters over any points.

 

[HSTEd]

ECP, while it can detect and react to a train split very quickly, doesn't inherently report length information, which is vital to determine the moment when the rear of a train clears a train detection section, to release junction locking for conflicting moves perhaps. An EOT balise reader 'paired' with a head unit, could plausibly determine very accurately when the tail has passed a particular balise previously passed by the head reader.

Digital ECP systems can bring many benefits including smoother more controlled braking, data channels for diagnostics both for the brake system and other important indications such as axle bearing temperatures, but to provide a cast-iron SIL 4 decision to release locking and allow a point to move I'd like to measure each time, which an EOT reader could provide. Even then I'd also have deadlocking axle counters over any points.

Well ECP will know if the train is still complete, and I don't think its unreasonable for any ECP fitted vehicle to know its own length.
The only additional check required to create a functional, accurate, recording of train length is for us to confirm that none of the vehicles in the train have faulty ECP comms units.

This could be done by the train crew, or alternatively a small number of axle counters would be able to confirm that the number of the axles in the train matches the number the ECP system thinks is in the train. This would only have to be done once for a block train, because after that the sequencing system knows which vehicle is at the end of the train, as well as how many vehicles are present.

Ultimately, we could also just assume that all freight trains are 775m long and simply not permit a train on the system that is longer than that.

EDIT:
If fault ECP units are in the train, we could allow train crew to enter a value for the length of dead vehicles, obviously preventing any negative values being entered, or simply default back to a 775m length assumption.

 

[zwk500]

ECP, while it can detect and react to a train split very quickly, doesn't inherently report length information, which is vital to determine the moment when the rear of a train clears a train detection section, to release junction locking for conflicting moves perhaps. An EOT balise reader 'paired' with a head unit, could plausibly determine very accurately when the tail has passed a particular balise previously passed by the head reader.

Digital ECP systems can bring many benefits including smoother more controlled braking, data channels for diagnostics both for the brake system and other important indications such as axle bearing temperatures, but to provide a cast-iron SIL 4 decision to release locking and allow a point to move I'd like to measure each time, which an EOT reader could provide. Even then I'd also have deadlocking axle counters over any points.

Even CBTC systems for metros use axle counters around points and so on.

Essentially what I have in mind is to ETCS-ify Absolute Block. Locations with points and conflicts are fully fitted with axle counters and conventional interlocking (either with ETCS L2 Block Markers or L1 Signals if L1-LS). The sections between the 'station limits' would be undetected, with Balise groups around stations and level crossings to activate equipment from the head of train transmitter and report positioning. The rear of train would than have a EOT device capable of transmitting a 'train complete' packet to release crossings or releasing a control in the interlocking to allow the following train to be issued an MA into the undetected section.

== Doublepost prevention - post automatically merged: 5 Jun 2025 ==

Well ECP will know if the train is still complete, and I don't think its unreasonable for any ECP fitted vehicle to know its own length.
The only additional check required to create a functional, accurate, recording of train length is for us to confirm that none of the vehicles in the train have faulty ECP comms units.

This could be done by the train crew, or alternatively a small number of axle counters would be able to confirm that the number of the axles in the train matches the number the ECP system thinks is in the train. This would only have to be done once, because after that the sequencing system knows which vehicle is at the end of the train, as well as how many vehicles are present.

How would this be done dynamically?

Ultimately, we could also just assume that all freight trains are 775m long and simply not permit a train on the system that is longer than that.

That's a significant amount of capacity being wasted if the interlocking won't release until the head of train is at least 775m beyond the clearance points...

ECP braking is great, and if you can have a control packet in the ECP comms unit that tells a wagon it's the last one in the train then that's not a problem. Then the question would come down to the relative value of fitting enough wagons that might end up on the end of a train with a balise reader and the enhanced comms unit, or if it's easier to just manufacture standard EOT tail lamps that have the comms unit and Balise reader fitted so they can transmit the 'train passed complete' data packet, regardless of anything that happens with the formation including faulty wagons, etc.
Given you're going to, at some point, have a formation running with vehicles dead-in-tow or with faulty ECP brakes/comms units, even if you had 100% ECP fitment on every rail vehicle on the network (unlikely) the EOT is likely required anyway so you're not reinventing the wheel.

 

[HSTEd]

How would this be done dynamically?

You could position axle counters at the exits of freight yards, sidings and the like.
The signalling system knows the maximum length of the train (775m or similar), so it knows when the entire train must have passed the axle counter.

The train would report that its stated length is x metres and that it has 32 axles. The axle counter would report that in the time between the front of the train passing the axle counter and the front of the train being at least 775m away (marked with balises with sufficient tolerance) that 32 axles were detected.

The signalling system could then mark that its train length is certified and can be assumed correct until some sort of train split or modification occurs.

This could be recertified whenever the train passes a convenient axle counter.
The system could also throw an alarm if the system keeps detecting axles when the 775m has passed but before another train could be present, which would detect overlength trains.

That's a significant amount of capacity being wasted if the interlocking won't release until the head of train is at least 775m beyond the clearance points...

I thought that, post coronavirus, aggregate trains had joined container trains in tending towards the maximum permissable length?
Those two categories make up a large and increasing share of traffic.
Do we have any kind of stats on the actual length of freight trains on the system?

How much capacity would be wasted?

ECP braking is great, and if you can have a control packet in the ECP comms unit that tells a wagon it's the last one in the train then that's not a problem. Then the question would come down to the relative value of fitting enough wagons that might end up on the end of a train with a balise reader and the enhanced comms unit, or if it's easier to just manufacture standard EOT tail lamps that have the comms unit and Balise reader fitted so they can transmit the 'train passed complete' data packet, regardless of anything that happens with the formation including faulty wagons, etc.
Given you're going to, at some point, have a formation running with vehicles dead-in-tow or with faulty ECP brakes/comms units, even if you had 100% ECP fitment on every rail vehicle on the network (unlikely) the EOT is likely required anyway so you're not reinventing the wheel.

I did once try to FOI stats on the number of mainline registered freight vehicles. ORR and Network Rail both didn't know - which seems like a bit of a strange oversight.
We know more about the number of cars on the road than vehicles on the railway, despite the latter being a more closely controlled environment!
But I think it is likely that only a comparatively small number of freight vehicles are actually in regular use.

The cost of fitment is likely to be small compared to the ongoing costs that are avoided - for example abandoning hot box detctors will save a substantial sum as they are very expensive.
I'd suggest that the best option for the railway would be to push to 100% fitment as rapidly as possible.

I don't know how practical it is to provide an EOT beacon that can reliably read balises though, what are the tolerances permissible on balise readers?
Can we get a mounting in a suitable position that is going to reliably read the balise?

 

[zwk500]

You could position axle counters at the exits of freight yards, sidings and the like.
The signalling system knows the maximum length of the train (775m or similar), so it knows when the entire train must have passed the axle counter.

The train would report that its stated length is x metres and that it has 32 axles. The axle counter would report that in the time between the front of the train passing the axle counter and the front of the train being at least 775m away (marked with balises with sufficient tolerance) that 32 axles were detected.

The signalling system could then mark that its train length is certified and can be assumed correct until some sort of train split or modification occurs.

This could be recertified whenever the train passes a convenient axle counter.
The system could also throw an alarm if the system keeps detecting axles when the 775m has passed but before another train could be present, which would detect overlength trains.

How is the train communicating with the Interlocking to cross-check that information?

I thought that, post coronavirus, aggregate trains had joined container trains in tending towards the maximum permissable length?
Those two categories make up a large and increasing share of traffic.
Do we have any kind of stats on the actual length of freight trains on the system?

Plenty of trains don't run anywhere near 775m due to the limitations of infrastructure it requires to stand clear inside. The Mendip/Peak Jumbos are a slightly different case, but generally only the heaviest container trains are getting close to 775m. And (in general) only the busiest container routes are 775m cleared.

How much capacity would be wasted?

Depending on the location, potentially quite a lot. But in busy areas, even a small amount of wasted capacity could be a serious constraint on service and performance. Although of course if you're in a fully track-circuited/axle counter area then on-train integrity proving isn't an issue, so you wouldn't need the interlocking to hold down for 775m, just for the relevant sections to occupy and then clear.

On-train integrity is only relevant when moving from an undetected area into a detected area in order to confirm the undetected area is clear. There would be sufficient detection approaching a junction for the train to be proven complete in the interlocking without any need for confirmation from the train. Of course, if the train has the ability to report it's tail clear anyway, there are various situations where this could be useful to avoid the need to fit additional equipment.

I did once try to FOI stats on the number of mainline registered freight vehicles. ORR and Network Rail both didn't know - which seems like a bit of a strange oversight.
We know more about the number of cars on the road than vehicles on the railway, despite the latter being a more closely controlled environment!
But I think it is likely that only a comparatively small number of freight vehicles are actually in regular use.

The cost of fitment is likely to be small compared to the ongoing costs that are avoided - for example abandoning hot box detctors will save a substantial sum as they are very expensive.
I'd suggest that the best option for the railway would be to push to 100% fitment as rapidly as possible.

Nevertheless there will still be cases when vehicles are not going to be fitted with ECP brakes, or may work with ECP inoperative.

I don't know how practical it is to provide an EOT beacon that can reliably read balises though, what are the tolerances permissible on balise readers?
Can we get a mounting in a suitable position that is going to reliably read the balise?

I don't see why it would be a particular problem, although it might need to be a 2-part kit (EOT holder on buffer beam, Balise antenna on separate mounting underneath)

 

[MarkyT]

Even CBTC systems for metros use axle counters around points and so on.

Essentially what I have in mind is to ETCS-ify Absolute Block. Locations with points and conflicts are fully fitted with axle counters and conventional interlocking (either with ETCS L2 Block Markers or L1 Signals if L1-LS). The sections between the 'station limits' would be undetected, with Balise groups around stations and level crossings to activate equipment from the head of train transmitter and report positioning. The rear of train would than have a EOT device capable of transmitting a 'train complete' packet to release crossings or releasing a control in the interlocking to allow the following train to be issued an MA into the undetected section.

I agree. Crossings might be activated and cleared, and additional intermediate headway block sections provided more cheaply with markers only and MA carried bu intermediate switched balises or intermittent radio coverage. It would be up to the train how it decided when the tail was clear of a virtual block. If a fixed formation MU, it could determine rear position from existing data stored on board and extrapolate from the known front reader position. If not available (either not equipped or system faulty), the cab system could REQUIRE an EOT device to be activated and paired before moving, then rely on that for all block clearance events (a rear cab of a MU might also be configured as an EOT for certain failure scenarios. A long supervisory axle counter section would still be monitored for a complete plain line section that is proved clear for block direction reversal or to clear intermediate virtual blocks that have been left falsely occupied due to malfunction. No additional counter sensors would be required. The long sections would be simply between the sensors required anyway for the zones of conventionally interlocked pointwork.