My (admittedly limited) understanding is that the SIGNUM-Integra replacement installed in Switzerland (as opposed to the ZUB replacement, which has a Euroloop) uses a balise to impose an instantaneous speed limit on the train passing over the loop based on the signal state. If the train is going faster than the set speed, either 0 for stop or some speed for caution, then the train will trip the emergency brake.
Signum is a very simple system based on magnets. It can therefore only distinguish three things due to the possible output (none, S-N or N-S): Free run (no input), warning or stop. It cannot monitor speeds. Only with tinkering solutions such as time-controlled switching of a magnet.
ZUB is also based on balises and optional loops, but is much more complex. Most of the SBB Network is/was equipped with ZUB additionally to SIGNUM. It sends data telegrams with target distance, target speed, gradient, line speed and other small details. This enables a continuous monitoring. The onboard device calculates a braking curve based on the train data (maximum speed, braking capacity, train length, braking type). An update can be sent out using an infill balise or a loop. The vehicle can only ever read the loop that was announced by a balise. Otherwise, loops in the opposite direction or from neighboring tracks would also be read. Loops are good for increasing capacity, but cannot influence a starting train. For this reason, balises are generally used at stations with starting or reversing trains, as they can stop an erroneously departing train before the danger point. However, this reduces capacity, as the upgrade of a signal aspect can only be sent to a train at certain points.
For rolling stock with Baseline 2, the SIGNUM magnets and ZUB balises have been replaced by ETCS balises which, however, transmit national data (ZUB data) in data packet 44. This is a 1:1 replacement, which replaces parts of the hardware. However, the ECTS Onboard Unit has nothing to do with these data, which are processed by the legacy hardware on the trains. No difference for the drivers (except for the technical stuff).
With Baseline 3, however, the ETCS telegrams are used and packet 44 is ignored. The ETCS standards also come into play here, i.e. braking curves and release speeds. ZUB does not have a release speed; the train driver must « free » himself if necessary and if permitted and not inhibited by the last telegram (<40 km/h). If he does this by mistake, hthe train can be stopped again by a balise or a loop. With ETCS, the release speed specified by the system is always automatically active and the train can only be stopped at the signal showing danger. With this system, a clearance behind the signal is therefore necessary or a very low release speed must be used. ZUB does not have this restriction. And this is also one of the main problems. You never know exactly when the monitoring of the braking curve will be replaced by the release speed and which release speed will be used (or even several in succession). But they have one thing in common: They are always active far too early. They require a driving style that deviates far too much from the performance the train is actually capable of. You look far too often at the display to see if a release speed is suddenly announced instead of concentrating on stopping the train in the correct place at the platform and before the signal.
In a TPWS or AWS replacement, couldn't you just set the speed to a precalculated value, analogously to the calculation used to position a TPWS "trigger" loop? That could be done with whatever braking curve you want couldn't it?
If I understand you correctly, this would be a step backwards from continuous monitoring to a punctual intervention. In addition, it would probably not be possible to monitor all permissible speeds according to train type and braking force. Depending on the rolling stock, these can be between 40km/h and 160km/h at the same point.
