Accident at Alton Towers
- Thread starter silenthillXD
- Start date
CoasterCrazy
Giga Poster
Actually, just checked the back of the Smiler's train and there is indeed an impact dampener, or whatever you want to call it. If they had had one on the front, perhaps the accident would have been alleviated...but either way, it's lucky they had a dampener on the back - otherwise this could have been significantly worse.
Robbie
Hyper Poster
Good to have a voice of reason. I've been a bit disheartened by the number of Alton Towers customers appearing in the news saying they knew it would crash because the ride had technical problems in the morning. On that basis, it would have crashed pretty much every day since it opened!Ian said:
MouseAT
Hyper Poster
The impact dampener only really helps at slow speeds, eg. a couple of MPH in the station. It won't help you at 50-odd MPH mid-circuit.
The thing I can't understand is why a train was released from the lift hill if the block ahead was occupied, unless the ride system somehow lost track of where the empty train was. Looking at ECG's POV of the ride, I can't see any obvious sensors on the track in that section of the ride. If the ride systems have been fully reset, does the ride lose track of where it thinks the trains were before the rest took place? If the empty train entered the block but never reached the sensor at the other end, the ride control systems would know something was wrong, but if someone managed to clear the error, how would the ride know there's a train stuck in the batwing if the ride doesn't have a sensor where the train came to rest? Under those circumstances, the control system would probably assume the block is clear, and allow the next train to enter. Pure speculation on my part, but it does make me wonder.
The thing I can't understand is why a train was released from the lift hill if the block ahead was occupied, unless the ride system somehow lost track of where the empty train was. Looking at ECG's POV of the ride, I can't see any obvious sensors on the track in that section of the ride. If the ride systems have been fully reset, does the ride lose track of where it thinks the trains were before the rest took place? If the empty train entered the block but never reached the sensor at the other end, the ride control systems would know something was wrong, but if someone managed to clear the error, how would the ride know there's a train stuck in the batwing if the ride doesn't have a sensor where the train came to rest? Under those circumstances, the control system would probably assume the block is clear, and allow the next train to enter. Pure speculation on my part, but it does make me wonder.
I see what you did there. :wink:CoasterCrazy said:
I'm not going to add to the speculation, but I don't think the coaster will be scrapped because of this or other issues it has had. I do however see the coaster being down for a very extended period of time to make sure no further issues occur. Isolated incidents, like others have mentioned, don't have lasting effects in guests minds, but continuous problems (especially ones involving injuries) will keep them from riding the coaster.
Smithy
Strata Poster
Aye, it seems strange that the ride would be stopped on the lift hill for 10-15 minutes as has been reported and then continued, would suggest (and it's nothing more than ignorant speculation) that an operator error 'could' have reset the system and restarted it but it's unlikely that they'd do so without at least checking that the train had cleared the next block.
CoasterCrazy
Giga Poster
^Yep, that does seem possible, although you'd think they would have procedures against that kind of thing happening.
It's funny, because I didn't even mean to do that.....I see what I did there now
Anyway, apparently, some of the ride staff were made aware by the GP of it - but perhaps they didn't manage to get the message through in time.
ECG said:
It's funny, because I didn't even mean to do that.....I see what I did there now
Anyway, apparently, some of the ride staff were made aware by the GP of it - but perhaps they didn't manage to get the message through in time.
ATTACKHAMMER
Strata Poster
Horrific incident. I hope the people involved make a full recovery. From personal experience I know and have seen how leg injuries can affect people (it's in my line of work).
I hope the investigation can give the answer to how this happened and what can be to improve things for the future.
I hope the investigation can give the answer to how this happened and what can be to improve things for the future.
mouse
Giga Poster
BBC News has released an update:
http://www.bbc.co.uk/news/uk-32980354
Also includes a history of the Smiler's previous issues which is worth a look at.
http://www.bbc.co.uk/news/uk-32980354
Also includes a history of the Smiler's previous issues which is worth a look at.
spicy
Giga Poster
^ It may not even be that easy to do? If it's even possible?
Either way this is all still pure speculation, but surely the computer shouldn't even let manual over ride be activated if a train has valleyed?
Or I'm just shocked that there's not some sort of warning lights or anything in place to tell a ride op that the train hasn't cleared the first block before a train can even leave the station.
This sort of thing just shouldn't ever happen. It's hard not to blame Gerst, even if the ride op makes a terrible mistake like dispatching a train whilst there is a train valleyed on the track. The ride hardware should still not let the train be dispatched no matter what.
It's just difficult to not blame the ride hardware. For example I bet this simply couldn't happen on a B&M.
Either way this is all still pure speculation, but surely the computer shouldn't even let manual over ride be activated if a train has valleyed?
Or I'm just shocked that there's not some sort of warning lights or anything in place to tell a ride op that the train hasn't cleared the first block before a train can even leave the station.
This sort of thing just shouldn't ever happen. It's hard not to blame Gerst, even if the ride op makes a terrible mistake like dispatching a train whilst there is a train valleyed on the track. The ride hardware should still not let the train be dispatched no matter what.
It's just difficult to not blame the ride hardware. For example I bet this simply couldn't happen on a B&M.
Smithy
Strata Poster
I'd be very surprised if there was a manual override that was used in this situation tbh purely because the ride op would have to be absolutely reckless to see the train on the lift for 10 odd minutes and not think to check why the empty one hadn't returned.
Suppose it's going to be a bit of a nuisance (in the grand scheme of things, it's absolutely **** all compared to the four youngsters suffering from potential life changing injuries) if it does turn out to be a Gerstlauer error as we'll probably not hear about it.
I mean I know it's silly and I'm a blatant hypocrite for it but I refuse to ride Intamin towers and I'm more nervous on Intamin launches than any other coaster because of the reported incidents with cables on either of them. Yet I got on Lisebergbanan fine, rode RMT not long after it's accident, but there's just something I've associated in my head with Intamin and cable issues that affects me more than just the usual pre-ride nerves.
Suppose it's going to be a bit of a nuisance (in the grand scheme of things, it's absolutely **** all compared to the four youngsters suffering from potential life changing injuries) if it does turn out to be a Gerstlauer error as we'll probably not hear about it.
I mean I know it's silly and I'm a blatant hypocrite for it but I refuse to ride Intamin towers and I'm more nervous on Intamin launches than any other coaster because of the reported incidents with cables on either of them. Yet I got on Lisebergbanan fine, rode RMT not long after it's accident, but there's just something I've associated in my head with Intamin and cable issues that affects me more than just the usual pre-ride nerves.
silenthillXD
Hyper Poster
According to the thread on Theme Park Review the BBC has reported that some of the injuries are described as "life changing" really not looking good here. Such a dreadful piece of news to come out of this terrible incident.
My only proper experience with block braking is from railway engineering, but I believe a coaster to work mostly the same. From that, I think I can picture a possible series of events that could lead to an accident like this:
I assume that the coaster has some sort of "default mode" when the system boots (AKA gets turned on for the first time in the morning). All blocks (at least those outside the station) would be marked as clear. If the blocks in the middle of the track were assumed to be occupied when the system boots up, it'd be impossible to send a train around, since the system would believe every block to be occupied until told otherwise, and you could only "tell it otherwise" by moving a train past the sensor.
There's a weakness to the block system, though: The coaster has no way to know where the trains are located, until they pass a sensor. The sensors would be located at the borders between each block, since there would be no need to have any sensors in the middle of a block (that would effectively only split the block into two half-blocks, without a brake in between). In other words, the system can't tell exactly where the trains are at any time, it can only tell when it passes a sensor. Everything that happens between the sensors is a complete mystery. The coaster can know whether a train has entered a block or exited it, but it can't explicitly tell whether there is a train in the block or not.
A block is only marked as occupied once a train enters it (by leaving the previous block). If the system is running, the block remains marked as occupied until the sensors at the next block border register a train passing. Meanwhile, the block brakes will only allow a train to pass if the next block is clear. This is normally a pretty good system.
A system reboot, though, might have set the coaster back in "boot mode", where all blocks are clear, maybe with the exception of the station and station brakes (as that would be the logical place for the trains to be located when the coaster starts up in the morning). The system won't then be able to determine that the track is obstructed, and it sends a train through as if every block is clear, because no block is determined to be occupied until a train passes the sensor. As such, it routinely dispatches the train on the lift hill, sending it into the next block, without knowing there's already a valleyed train in there. Cue collision.
So what might have happened would be a reboot happening after a train was dispatched. Why, I have no idea. The train is resting on the lift hill, the coaster refuses to send it further, and somehow the system is rebooted. The restart, taking a few minutes, wipes the memory of all the blocks, and marks them all to be clear. Once that is done, the train on the lift hill is sent into the next block, where a valleyed train is sitting.
If so is the case, well, it'd be a serious break of procedure. Either human error (which would be grave negligience) or the system itself rebooting on its own, maybe after losing power. Since the system can't determine whether a block is occupied or not upon startup, the boot procedure should involve a check to see if everything is clear. In hindsight, the best way to do this would be to have the system mark every block as occupied once the system boots, requiring a flip of an override switch for every block - and the switches would be located only next to the sensors, forcing a proper track walk when the system starts up. Inconvenient as heck, but it'd make the boot procedure a lot safer.
Of course, a system relying entirely on block sensors is pretty bare-bones, and that sounds too simple to me, considering the inherent flaw described above and the availability of redundant systems. I believe there might be backups. There could be a secondary system sending a weak electric current through the rails, ensuring that the track forms a complete circuit. Any trains in the block would short-circuit the system, signalling that something obstructs the block. A system of this fashion is used on some railway lines, though I'm not sure if coasters could do the same, due to polyurethane wheels being a poor conductant and possibly unable to short-circuit the current.
One might work out something with acoustic pulses instead, since the presence of a train would clearly interrupt any signals (the "echo" of the track, if you'd like). Still, so would rain or wind or (I believe) material expansion or contraction due to temperature, so a system like that, unless carefully calibrated, would produce a lot of false error messages.
You might even work out a system with a magnet on every train, inducing a weak electrical current in the rails as it goes. This would send a signal to the sensors that a train is in the block, but if the train were to stop, there'd be no induced current.
Either way, there should be a backup. Something that'd make the "uhh, something's amiss" lamp blink. It should not be possible to miss a valleyed train, and it should not be possible for a recently booted system to automatically assume everything is clear. It's hard to make a system capable of making a proper inspection, though, so it is dependant on a human telling everything is ready before a train can be dispatched. If said human tells the system everything is ready before inspecting, though - which might have no consequence 99 times out of every 100 - a mistake is ready to happen.
Either way, it's almost dead certain that the riders themselves were not at fault. Too bad for them, they were just sitting in the wrong chairs at the right time, literally wrapped in security measures ensuring them everything would be safe. It very sad to see a system like that fail, and doubly so when the consequences were bore by innocent people who had no agency over the outcome. What reason did they have to not think they were perfectly safe? What could they do, once they realized something was amiss? Nothing, that's the answer to both questions. And now they're suffering for it. Hopefully, they'll be fine again, and soon.
I assume that the coaster has some sort of "default mode" when the system boots (AKA gets turned on for the first time in the morning). All blocks (at least those outside the station) would be marked as clear. If the blocks in the middle of the track were assumed to be occupied when the system boots up, it'd be impossible to send a train around, since the system would believe every block to be occupied until told otherwise, and you could only "tell it otherwise" by moving a train past the sensor.
There's a weakness to the block system, though: The coaster has no way to know where the trains are located, until they pass a sensor. The sensors would be located at the borders between each block, since there would be no need to have any sensors in the middle of a block (that would effectively only split the block into two half-blocks, without a brake in between). In other words, the system can't tell exactly where the trains are at any time, it can only tell when it passes a sensor. Everything that happens between the sensors is a complete mystery. The coaster can know whether a train has entered a block or exited it, but it can't explicitly tell whether there is a train in the block or not.
A block is only marked as occupied once a train enters it (by leaving the previous block). If the system is running, the block remains marked as occupied until the sensors at the next block border register a train passing. Meanwhile, the block brakes will only allow a train to pass if the next block is clear. This is normally a pretty good system.
A system reboot, though, might have set the coaster back in "boot mode", where all blocks are clear, maybe with the exception of the station and station brakes (as that would be the logical place for the trains to be located when the coaster starts up in the morning). The system won't then be able to determine that the track is obstructed, and it sends a train through as if every block is clear, because no block is determined to be occupied until a train passes the sensor. As such, it routinely dispatches the train on the lift hill, sending it into the next block, without knowing there's already a valleyed train in there. Cue collision.
So what might have happened would be a reboot happening after a train was dispatched. Why, I have no idea. The train is resting on the lift hill, the coaster refuses to send it further, and somehow the system is rebooted. The restart, taking a few minutes, wipes the memory of all the blocks, and marks them all to be clear. Once that is done, the train on the lift hill is sent into the next block, where a valleyed train is sitting.
If so is the case, well, it'd be a serious break of procedure. Either human error (which would be grave negligience) or the system itself rebooting on its own, maybe after losing power. Since the system can't determine whether a block is occupied or not upon startup, the boot procedure should involve a check to see if everything is clear. In hindsight, the best way to do this would be to have the system mark every block as occupied once the system boots, requiring a flip of an override switch for every block - and the switches would be located only next to the sensors, forcing a proper track walk when the system starts up. Inconvenient as heck, but it'd make the boot procedure a lot safer.
Of course, a system relying entirely on block sensors is pretty bare-bones, and that sounds too simple to me, considering the inherent flaw described above and the availability of redundant systems. I believe there might be backups. There could be a secondary system sending a weak electric current through the rails, ensuring that the track forms a complete circuit. Any trains in the block would short-circuit the system, signalling that something obstructs the block. A system of this fashion is used on some railway lines, though I'm not sure if coasters could do the same, due to polyurethane wheels being a poor conductant and possibly unable to short-circuit the current.
One might work out something with acoustic pulses instead, since the presence of a train would clearly interrupt any signals (the "echo" of the track, if you'd like). Still, so would rain or wind or (I believe) material expansion or contraction due to temperature, so a system like that, unless carefully calibrated, would produce a lot of false error messages.
You might even work out a system with a magnet on every train, inducing a weak electrical current in the rails as it goes. This would send a signal to the sensors that a train is in the block, but if the train were to stop, there'd be no induced current.
Either way, there should be a backup. Something that'd make the "uhh, something's amiss" lamp blink. It should not be possible to miss a valleyed train, and it should not be possible for a recently booted system to automatically assume everything is clear. It's hard to make a system capable of making a proper inspection, though, so it is dependant on a human telling everything is ready before a train can be dispatched. If said human tells the system everything is ready before inspecting, though - which might have no consequence 99 times out of every 100 - a mistake is ready to happen.
Either way, it's almost dead certain that the riders themselves were not at fault. Too bad for them, they were just sitting in the wrong chairs at the right time, literally wrapped in security measures ensuring them everything would be safe. It very sad to see a system like that fail, and doubly so when the consequences were bore by innocent people who had no agency over the outcome. What reason did they have to not think they were perfectly safe? What could they do, once they realized something was amiss? Nothing, that's the answer to both questions. And now they're suffering for it. Hopefully, they'll be fine again, and soon.
Smithy
Strata Poster
In the pictures I have seen those on the front row (bar the lad with the bloodied face) appears to be relatively calm, all things considered. Desperately hoping by severe leg injuries we're talking about multiple fractures at worst and not anything more life-altering as I've seen in a few places now.
Nick Varney gave an interview on Sky News and the bloke looked properly shaken by it, as I imagine most of the staff in the area will have been too.
Nick Varney gave an interview on Sky News and the bloke looked properly shaken by it, as I imagine most of the staff in the area will have been too.
SaiyanHajime
CF Legend
Manual overrides are for when the ride is in the hands of a technical team. I wouldn't have thought regular staff would even know how to do that and I would have thought guests are not permitted on a ride in the hands of technicians.
I don't think this is the fault of staff. Yes, they should have noticed the train didn't come back. Yes, they should have seen on CCTV it stalled. But break downs are stressful and in the time following them, there's a lot of pressure to start loading guests quickly. The computer should be there to compensate for human errors, with fail safes to prevent this from happening. It shouldn't be possible during normal operations for a train to leave a block section, be that a lift or set of brakes, until the next block is clear.
I don't think this is the fault of staff. Yes, they should have noticed the train didn't come back. Yes, they should have seen on CCTV it stalled. But break downs are stressful and in the time following them, there's a lot of pressure to start loading guests quickly. The computer should be there to compensate for human errors, with fail safes to prevent this from happening. It shouldn't be possible during normal operations for a train to leave a block section, be that a lift or set of brakes, until the next block is clear.