Incident on The Smiler 02/06/2015

[Stuntman707]

I actually feel slight relief knowing that at least the ride did exactly what it was designed to do. I still think even after a complete hard reset, the ride should re-detect where all the trains are in the blocks.

 

[delta79]

Maybe that could be a upgrade to the software. I wonder if there will be a senor in the bottom of the loop? To detect stalled cars.

 

[Alexsutton]

But the system knew there was a stalled car?

 

[Leah]

Maybe have sirons in the ops cabin so if it detects a stalled car everyone knows about it

 

[delta79]

I know, however if there was a senor to tell the system after a reset then the system would go into unclear block mode again.

 

[UserDeleted]

Maybe have sirons in the ops cabin so if it detects a stalled car everyone knows about it

This actually is a really easy but clever solution. Maybe not a siren to alert everyone, but maybe to alert the ride op and the guys at the front of the queue so they could confirm between each other any problems.

 

[Pepper_Plant]

Maybe even just having something very obvious about its reasons for stopping the ride. For example if the ride stopped because a train didn't get to the second sensor (as it seems happened) then on restart it could have a warning saying 'stalled train detected, confirm this has been removed'.

 

[AliceHL91]

Or "oh no, it's happened again!"

 

[Leah]

Wouldn't want to be working on the smiler if it stalled. After this though, don't you think that if they got a message saying "stall detected" or something they would inspect every part of the track 6 times before sending it, through panic of it happening

 

[micksalt]

Simple solution, make a bracket on the batwing, hang the hard-reset key from it, That way, each time they need the key, operators are forced to acknowledge that there's a stalled car in the way

 

[micksalt]

But seriously, it's virtually impossible to eliminate the requirement for hard-reset. These systems only know when something has entered the section, and when they have exited, if a train is removed by crane, it doesn't pass the section exit sensors so the hard-reset is required to clear the block. However, the boot-sequence after a hard-reset should commence with an audit system where the operator has to manually input where each of the trains are. That would force the operators to review where everything is, and you would set up the system so nothing moves until all that data is input, and it checks the logic of the data before starting.

 

[Alexsutton]

But seriously, it's virtually impossible to eliminate the requirement for hard-reset. These systems only know when something has entered the section, and when they have exited, if a train is removed by crane, it doesn't pass the section exit sensors so the hard-reset is required to clear the block. However, the boot-sequence after a hard-reset should commence with an audit system where the operator has to manually input where each of the trains are. That would force the operators to review where everything is, and you would set up the system so nothing moves until all that data is input, and it checks the logic of the data before starting.

But that still relies on the input of the user. That could well be exactly what happened but because of the error of the person inputting the data, the system could still think that all was correct.

 

[Stuntman707]

But seriously, it's virtually impossible to eliminate the requirement for hard-reset. These systems only know when something has entered the section, and when they have exited, if a train is removed by crane, it doesn't pass the section exit sensors so the hard-reset is required to clear the block. However, the boot-sequence after a hard-reset should commence with an audit system where the operator has to manually input where each of the trains are. That would force the operators to review where everything is, and you would set up the system so nothing moves until all that data is input, and it checks the logic of the data before starting.

But that still relies on the input of the user. That could well be exactly what happened but because of the error of the person inputting the data, the system could still think that all was correct.

Having the system checking all the sensors after a reset eliminates human error. I don't think it would hamper the ability to reset the ride when required. A sensor should not still be triggered after a reset and if it is, the computer should not be allowed to forget that there is a problem. If the track is still clear, then it will fully reset as normal.

 

[Alexsutton]

Having the system checking all the sensors after a reset eliminates human error. I don't think it would hamper the ability to reset the ride when required. A sensor should not still be triggered after a reset and if it is, the computer should not be allowed to forget that there is a problem. If the track is still clear, then it will fully reset as normal.

Only if you install sensors every couple of metres, all the way along the track.

 

[smudge]

But that still relies on the input of the user. That could well be exactly what happened but because of the error of the person inputting the data, the system could still think that all was correct.

Totally.

Almost all possible outcomes will be 'human error' - its the same with any situation.
For example:
The op set the ride into manual and sent the car round - obviously human error.
The op forgot to engage 'reverse' before restarting the ride - again, obviously human error.
The track broke - think House on Haunted hill - still human error, noone checked the track
No-one's job was to check the track - human error, noone implemented a safe process
The software failed - human error, the system wasn't programmed correctly
The system should never have been reset - human error...

I could go on for every possible outcome and the route cause on 99% of instances, is, you guessed it, human error. It's just the degree of negligence that differs.

Pretty much the ONLY time it wouldn't be human error would be unforeseen natural disaster. Even if a tree fell on the track - that's still human error - no-one checked the safety of the tree near the ride. No-one done a survey of the area. Obviously the degree of negligence would be somewhat less however.

 

[micksalt]

Are we moving into the realms of Continuous Section Occupation Sensing? It's not actually that difficult, you just have two contact strips that run in between the tracks, and a mini-pantograph arrangment on the bottom of the carts that completes the circuit when it is in that section. On hard-reset, the system can see which sections are occupied and apply the usual safety logic that blocks work on.

Then again, it's got enough problems with stalling without adding the tiny bit of friction that this system would add.

In fact, if you wanted to be really clever, with a four-rail system, it'll even be able to identify the train that's in the section by each train having a different bridging arrangement.

 

[Alexsutton]

All of that relies on the contacts never failing. If it fails, then you're back to the same situation where there is a vehicle on the track the computer doesn't know about.

 

[micksalt]

All of that relies on the contacts never failing. If it fails, then you're back to the same situation where there is a vehicle on the track the computer doesn't know about.

That's a double-failure though, in fact, triple if you count the stall. Can never reduce the failure rate to zero, but another layer will reduce it significantly. The system works well in signalling systems on the rail network.

Going to revise that to double-failure, hard-resetting the system and a stall are not independent enough for my liking. Chances are that it's being reset because of a stall.

 

[LordOfDarkness]

There's hardly any way of telling if anything has moved for a while, so the ride car in the station has its harnesses up, if they're down in the future maybe it has signs of life!

 

[delta79]

I think clean scrub marks on the track would show signs of life