Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Remote control systems can and will fail.


I don't know what's considered a safe speed for moving a train without working safety systems on a European high-speed railway, but it's almost certainly so slow (20-40km/h) that the system is designed such that failure of the control system is extremely rare. Should it fail, the priority will be to restore it, rather than move trains around very slowly.


On-train systems will stop the train in case of failure.

I was responding to “Why not have people in a control room drive the trains, coordinating the system as a whole”. Infrastructure and timetables are centrally coordinated (or actoss several centers). Controlling a train remotely introduces multiple points of failure:

- connection lag

- connection quality

- remote operators don’t have the full details on a train (unless you have one operator per train)

Remote/automatic control works in smaller systems (such as subways, see e.g. Copenhagen), but the speeds there are usually smaller, the “fleet” is smaller, you can reach the trains in case of failure faster etc.


I don't see why this is an issue. If it fails, the train should stop. The train should be designed such that it only continues on its way if a continuous "okay to proceed" signal is received, gated on automatic safety systems and deliberate human action. Even if you have a driver, the train should still stop if it cannot communicate, because the driver can't determine whether the track ahead is safe.


Railroads were developed in a time when “continuous communication” wasn’t even a fiction, much less reality.

I don’t know what continuous monitoring/communication brings other than numerous new failure modes.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: