←back to thread

A computer upgrade shut down BART

(www.bart.gov)
232 points ksajadi | 3 comments | 05 Sep 25 14:52 UTC | HN request time: 0.615s | source
Show context
phkahler ◴[05 Sep 25 15:32 UTC] No.45139746[source]▶
It'd be pretty cool if busses and trains were local-first.
replies(2): >>45139769 #>>45140090 #
gjsman-1000 ◴[05 Sep 25 15:34 UTC] No.45139769[source]▶
If you can't send updated schedules or emergency alerts through the system, I also don't want service started. It doesn't have to be an individualized problem to render local-first useless.

Also, what do you mean by trains being local-first? Trains by definition need to share the same tracks with catastrophic consequences for getting it wrong. You can't figure out if a train is going to possibly be on the same route locally, or if your route has been obstructed. Somebody gets a schoolbus stuck on a crossing, it takes over a mile to stop a train.

replies(5): >>45139826 #>>45140427 #>>45140633 #>>45140774 #>>45144247 #
1. wongarsu ◴[05 Sep 25 16:56 UTC] No.45140774[source]▶
Trains traditionally operate on signalling blocks: a section between two signals is a block, a block is occupied if any part of a train is inside of it, if it's occupied any signals leading into the block are red. This can be decided entirely locally (as in: local to the block). When a wheel sensor detects a wheel entering the block, the block is occupied, signals switch to red and the number of wheels is counted. As soon as another wheel sensor counts an equal number of wheels exiting the block the block is free and signals switch to green. You need a wire along the block to communicate this, but from a safety perspective there is no need for global communication.

Modernization efforts focus on trains broadcasting position and speed so trains can travel closer together and still maintain a safe stopping distance, but that's again possible locally.

Operating switches is where it gets trickier. Some rail operators maintain the possibility to operate them locally, but that requires either stopping the train at each switch you want to change, or to deploy lots of people into the field to do it on schedule

replies(1): >>45142336 #
2. 0xffff2 ◴[05 Sep 25 19:03 UTC] No.45142336[source]▶
Not quite that easy. What if two trains are both traveling towards separate green signals into the same block such that the second train gets a red signal, but not in time to stop? I think it's possible to overcome this, but it become vastly more complicated than just "turn the signals red for the current block if it's occupied".
replies(1): >>45142741 #
3. wongarsu ◴[05 Sep 25 19:38 UTC] No.45142741[source]▶
You are right, reality is more complicated. In reality some blocks need more than two states and need to know the state of adjacent blocks. For example in a one-way track with two every points you would want to deny entry from one entry point if the track leading to the other entry point is occupied, to solve your case. And you probably want to call that state "reserved" instead of "occupied" to prevent a cascade if you have multiple such blocks right after each other.

But the point that you can do this local-first is still true. You will want to engage a couple bits of information with the neighboring block, but you don't need to know any global state, and if one block breaks down that only affects its direct neighbors