iggldiggl
The former was an actual safety-critical error in the LZB software, leading to the rear train getting an erroneous movement authority after a restart of the LZB control centre. This was fixed with a corresponding software update.
The latter was indeed somewhat comparable to the current situation – a train operating under LZB in partial block mode dropped out of LZB, and the signaller didn't properly verify whether the line ahead was clear before authorising the train to restart and did lead to on-sight running being mandated for that kind of situation (dropping out of LZB in partial block mode).
Besides, even if you switched to some new, completely-blank-slate system of tracking time, those associations would quickly redevelop since presumably most people will predominantly deal with local events within their own time zone. Only now with added confusion when you do encounter a foreign time reference after all…
The thing is, those "global time" proposals don't change anything about the fact that you have to look up local time and/or local customs when scheduling events in foreign timezone – you have to do it today, and you still have to do it even with a single global wall clock time.
The only thing it does – resolve some potential (potential, not definite!) ambiguity around what (wall clock) time exactly cross-time zone events are taking place, but at the price of completely breaking any association between clock time and the solar day. Personally, I don't think that's worth it.
> "School starts @740"
Which precisely illustrates the problem – because you didn't mention a location, that sentence is now completely meaningless. If I encountered it in a random story – does it mean that it is in the morning (but early morning or late morning or what?), is it in the afternoon…?
Like I said, I posit that most people regard the association between clock time and solar time as an advantage, not as a drawback.
> You could easily have a 'multiple calendar days during one solarday' situation.
I didn't say that this doesn't already happen today, but today it affects far fewer people in mostly less important ways.
That should have read "how to ensure that the train (driver) follows the directions given by the signalling".
Single track means that at least outside of stations, collisions can be reliably identified without much danger of false positives (and for station areas you can just institute a blanket speed limit to compensate for the gap in RCAS coverage, which might not even be any lower than the speed limit required for traversing diverging/spring-operated/hand-operated points there anyway), and no already existing full-scale signalling system means that RCAS actually provides a significant safety benefit and is therefore likely worthwhile from a cost-benefit-analysis point of view, too, if you're actually regularly operating multiple trains simultaneously on that kind of infrastructure.
Whereas on multi-track mainline railways avoiding false positives is much harder and normally you should already have proper signalling and train protection systems in place anyway, so the additional safety benefits of RCAS would be much more marginal.
Self-driving cars aren't supposed to drive quicker than they can look ahead, which makes the problem way easier because you don't have to figure out how to detect obstacles ahead of time and can simply rely on vehicle-local information to stop if necessary. And because cars can brake way more rapidly than trains, it means you can still drive reasonably quickly even within that limitation.
Plus in an emergency, cars have steering as an additional degree of freedom to attempt getting out of any nasty situation that may have developed.
(And of course the socially expected safety standards for cars are quite a bit lower than for public transport…)
Trains on the other hand have braking distances on the order of a kilometre or so, and high-speed trains at full speed several kilometres, so trying to get by on local data only is hopeless and the usual strategy is instead having central signalling system that can accurately track trains and coordinate their movements.
What we're talking about here is some sort of TCAS-equivalent for the case where the central signalling is down – while it's easy to accurately localise trains with the aid of a central signalling system that authoritatively knows about the infrastructure layout, it's quite more difficult when you're trying to do the same thing in a decentralised, train-local fashion.
No, it wasn't, from the way things have presumably played out, the scenario has simply hit an inherent design limitation. Namely LZB (https://en.wikipedia.org/wiki/Linienzugbeeinflussung) is the primary signalling and train protection system, but as a fallback, conventional colour-light lineside signalling together with the corresponding conventional train protections system (ASFA) has also been provided.
As a fallback system however, the lineside signalling has been set up with much longer signalling sections than the LZB, i.e. one conventional signalling section comprises multiple LZB signalling section. As such, it is still perfectly safe and serviceable, with the only immediate drawback that capacity will be significantly reduced due to the longer signalling sections (and also slower running speeds – the lineside signalling is limited to 200 km/h max).
The only problem comes in when you need to make an unscheduled transition from LZB to lineside signalling because of an LZB fault – while at first the trains will be safely braked to an immediate stop, you may now have ended up with multiple trains (all safely inside their own LZB block section) within the same lineside signalling block section. Which means that now there is no "next red semaphore" to prevent the second/third/… train from running into the train in front.
The proper procedure therefore is to untangle the trains by running them out of that accidentally shared block section one at a time and most likely at a reduced speed, too, but for some reason that procedure wasn't followed here…
Yeah, but within that approximation it's still very useful to be able to immediately have a rough idea without having to explicitly look it up each time. Plus like I said, calendar date/weekday changes happening during the middle of the day would be the much bigger annoyance…
You're confusing AWS and TPWS – AWS is the older system (based on pre-WW II technology but only deployed nationwide after WW II) which sort of roughly fits your first sentence, while TPWS will actually stop you if you're trying to pass a signal at danger (with the caveat that most automatic signals on the plain line aren't fitted on the basis that a train will relatively rarely actually have to stop at one – statistically that's absolutely sensible if you only have a limited amount of money and want to cover the higher risk signals first, but unfortunately the recent Elstow train crash did manage to hit that particular gap in the system…).
> But even then, an inquiry asked to look specifically into ATP determined we were right to reject it, it was just Too. Fucking. Expensive.
But you did eventually get TPWS which does deliver a quite large fraction of the safety benefits of ATP at a significantly smaller fraction of the costs.
LZB (the "German system that is more advanced that basic electrical fault based system") does 2. and 3., but in its usual mainline implementations still needs a conventional train detection system.
> it was just switched off because it was broken. That's downright reckless, and it shouldn't be a normal behavior.
The Spanish line in question is actually equipped with conventional colour-light signalling (and the corresponding conventional train protection system) as a fall back, which is perfectly safe, too.
The only critical bit (which by the looks of it unfortunately failed here) is managing an unplanned transition between the two, because for reasons of cost, the fallback signalling utilises much longer block sections than the LZB signalling, so if the LZB fails unannouncedly, you can end up with multiple trains (each inside its own dedicated LZB block section) inside the same line-side signalling block section, so restarting the train needs to be safely managed by getting them out of the accidentally shared block section one at a time.
The signalling system has already all the necessary data here, the trains by default none to few of it.
Hence it is usually way more tractable to just improve the reliability and functionality of the signalling system itself and don't bother with complicated technical fallback solutions.
(Things might look differently if you've only got single track lines and no modern signalling system in place – in that case a TCAS-like system might be worth it and not too difficult to implement, especially if you limit its scope to the plain single track line outside of station areas.)
Flying is different – the difference between your positional accuracy and the minimum safe separation between planes is way more favourable, so detection of potential conflicts is much easier.
And – while these days air traffic controllers do usually have computerised aids available to detect impending traffic conflicts, ultimately the system still relies on controllers correctly detecting any conflicts, issuing the correct commands to pilots, and those pilots then correctly executing those commands, too. That's a lot of human in the loop, so the impetus for some fallback safety system (TCAS or whatever) is much stronger.
With trains on the other hand, the default state for any kind of remotely modern signalling (for at least a few decades already, actually) is that the signalling is able to automatically ensure that the route is set correctly, that no conflicting routes are set and that no other trains are occupying the route. Likewise, even without full automated driving it is still possible to ensure that trains are actually following the commands of the signalling.
Hence with railways, the appetite for a completely secondary technical fallback systems to cover outages of the primary signalling system has been much lower, and like I said, it is usally more tractable to try improving the safety and reliability of the primary signalling system. (Though yes, for the fallback case you also need to properly prepare appropriate manual procedures that take into account the increased failure risk of manual operations…)
A very useful property of the current system is that calendar days are aligned with solar days and the change of calender date consequently happens when most of the population is either asleep or otherwise not too fussed about the exact date.
UTC-only (or equivalent "global time" proposals) breaks that for everybody not living near wherever the meridian ends up, which causes a lot of weirdness when a single calendar date can suddenly refer to two completely different solar days and two completely different wake cycles.
Additionally, such a proposal would also break all clock time references in fiction, especially when reading works set abroad or in some unspecified (but still Earth-like) setting, but I guess if you don't care about the calendar date weirdness, you wouldn't care about that, either…
Which means that
a) textual time references in stories would stop working unless also specifying a location, which would cause a lot of weirdness, especially in fiction
b) perhaps more importantly for day-to-day life, it causes a lot of weirdness around the change of the calendar day and the weekday. It's a rather useful property of the current system that the change of calendar day happens at a time when most people are asleep or otherwise not too fussed about the exact calendar date.
If you completely abolish time zones, that means that for everybody not lucky enough to live near wherever the meridian ends up (which would always be a significant fraction of the world's population, no matter where you'd place the meridian), the change of calendar date would happen during the middle of the waking hours, which causes a lot of weirdness (do public holidays now actually start and stop in the middle of the working day?) and makes date references vastly more cumbersome because a single calendar date can now refer to both solar n in the afternoon/evening and solar date n+1 in the morning.
So you'd have to start using rather awkward double dates for referring to a certain solar day ("the event will take place from the 22/23rd to the 24/25th", "see you on Thursday/Friday" [which isn't the same thing as "see you on Thursday or Friday" today, because that'd become "see you on Thursday/Friday or Friday/Saturday" under the new system properly]), or else develop some convention based on the local solar noon/midnight, which is basically reintroducing time zones through the back door.
Which might not play nice with rooted phones/unlocked bootloaders, either.
With such a setup, the traffic lights controller can't actually see that there's only 4-5 cars approaching on the main road – either they're far away enough that they don't even register on the detector for the main road yet (in which case a vehicle waiting on the crossroad will naturally trigger the phase change without delay), or even if they're already near enough to the intersection to trigger the detector, the traffic lights controller can't actually know that it's "only" 4-5 vehicles and its strategy might hence be that if the main road has had more than x seconds of uninterrupted green time, a demand from the side street will be granted immediately, regardless of traffic conditions.
With a state-of-the-art system it'd be different – with more and better sensors the traffic lights controller could actually track individual vehicles (or platoons of vehicles) as they approach the intersection and try making the kinds of trade-off you mention – but somebody needs to pay for that kind of upgrade. (And I suspect we haven't necessarily reached the point where the price premium for that kind of advanced traffic lights controlled compared to classic traffic actuation is negligible enough for it to be the default at least for all new intersections and equipment renewals, either…)
And everybody's favourite, apps that have been region-locked to local-inhabitants-only, because foreign visitors don't exist, right?
> The problem is the tracking and invasion of privacy, and that all traces back to ads.
The other problem is, what happens when your phone breaks? With more and more things slowly becoming app-only or mandating smartphone-based 2FA, we're slowly getting to a point where when your phone breaks, you're going to have major difficulties buying a new replacement phone in the first place.
At least partially that's actually the law as well – the default mode for new rail-road crossings is mandated to be grade-separation, with exceptions to that rule decided on a case-by-case basis, though primarily only in cases of low traffic (which in case of roads means ≤ 100 vehicles/day). Plus in actual practice the federal railway authority also having a reputation for a strict interpretation of that paragraph and tending to not grant exceptions has also done its thing, so in practice new level crossing on the federally-operated railway network (i.e. DB) are indeed a total rarity.
If you want to use the standard port, that's only true as of very recently, though, see https://issuetracker.google.com/issues/218578943#comment17
Problem is when there's multiple stations nearby and which one has the quickest connection varies depending on when exactly you leave. In that case manually checking every combination of stations could be somewhat cumbersome, especially if there's a choice of stations at both ends…
And +1 to the lack of railway lines when zoomed out, indeed another annoyance along the above lines.
Even a few years ago when phones with replaceable batteries weren't that rare and I was in possession of one – by the time I started thinking about a battery replacement, offers of original OEM batteries usually seemed to have vanished into thin air and it was having to find out which aftermarket battery seemed reputable enough…
Trains on the other hand are decidedly physical things that take up a significant amount of space on the infrastructure, and they do so as soon you start offering the service, no matter whether people actually use it or not. This means that railway networks can only support a very limited amount of competing companies before you start running out of capacity to run additional trains, and it's especially easy to run out of capacity when you're talking about mixed-traffic railways where fast long-distance services intermingle with slower regional and/or freight services.
And as soon as you run out of capacity, train operating companies have to start battling each other for train paths instead of passengers, a situation that can have completely different incentives which aren't necessarily best aligned with passengers' actual interests.
Another difference is that competing trains obviously cannot run at exactly the same time, which again makes competition less efficient because trains running at differing times cannot be perfect substitutes for each other, which becomes relevant once you add passengers' external schedule-constraints (having to arrive in time for work or whatever appointment they might have and maybe cannot really influence) into the mix. (Long-distance leisure travel is probably less affected by that, because people are regularly willing to flex their schedules for that, but other kinds of traffic aren't as flexible.)
This effect then only gets magnified further once connections come into play, because with different trains along the same route always having to be separated by at least a few minutes, it's impossible to offer equally attractive connections between e.g. a branch line (which might run only hourly or half-hourly at best) and all the various hypothetical competing services on the main line.
Which means you also need to battle the housing problem, too, though, plus changes in settlement patterns take years to decades to manifest. In the meantime, you might have to weather quite some griping about it or even serious pushback.
In simplified overviews, Windows counts file system caches (standby memory) as free (respectively available) memory, so if 77% of 32 GB is to be taken literally, it still sounds rather on the high side.