Seat mechanism on BORG Assimilator fails
pkidelirium said:
The trains on Firehawk and Batwing are different than Borg.Borg uses a mechanical system in the station to raise and lower the trains, and locking pins that hold them in the "Fly" position. Firehawk and Batwing have the onboard system.
If I'm not mistaken both Batwing & X-Flight/Firehawk also have a locking mechanism similar to Borg's.Take a look at the chassis when the ride is in the "load" position & you'll see the holes on each side of the chassis that the pins lock into after the seats are lowered into position.
The GAU's only raise/lower the seats without the need for station mounted lifting jacks,which Borg requires.
pkidelirium said:
http://www.wsoctv.com/news/11308720/detail.htmlI call BS.
Wow! Just WOW!. I won't claim to know much about the operation of coasters but that is just poor design.
I hope the ride does open Saturday as I am stopping at Carowinds that day on my way to Florida.
When major CF rides fail due to purely mechanical issues, they say so. When they find the issue, but aren't sure how that came about, they say so. When trouble lights indicate a fault prior to a failure--only they couldn't fathom what it was, they'll tell you that, too.
They're a publicly owned company that believes in full disclosure and has better things to do than create lil' so-called 'coverups' for armchair detectives to 'uncover.'
I'm not telling you that because I'm some CF fanboy (and frankly, most folks know better). I'm telling you that because it simply IS.
-CO
NOTE: Severe fecal impaction may render the above words highly debatable.
First of all we still have no idea what sort of a safety mechanism would just stop a train anywhere on the course. I highly doubt they have equipped the trains with braking mechanisms should the pins unlock. A much easier, cheaper, lighter way of doing things would have a backup mechanism to prevent the chassis from opening during the ride, should the pins fail.
As for the report that someone accidentally pushed a button, now in my mind theres no way that can happen. That would mean that somehow the button being pushed would have to communicate with the ride. Almost all rides only have communication like this in the station to prevent something like this happening. That is why when a ride is being manually released its a much longer process including many manual release tools and in some cases battery packs to bring power to the ride. Now I know that it is possible that these rides may be different than all others, I'm not saying I know everything about them, but having communication like that throughout the ride course would cause a lot of errors especially being a Vekoma. Not to mention there is no real need to be able to communicate with the ride outside of the station, not a good enough reason at least to require adding a lot more to the trains and an expensive most likely wireless (and flawed) communication system.
So say all that we are hearing is true, fine. Like pagoda gift shop said though if it is in fact true, this is easily a user error thing that we should have seen in the past. The only other explainable way is if there is a manual unlike on the actual train, and one of the employees pushed it during the ride. If thats the case, it wasn't an accident, but that would have been something done intentionally which I doubt a rider would want to do to them self. If it was accidentally hit on the train, then again why havn't we seen this happen before?
The whole story is very fishy and I would like to find out some information that will make sense.
While in the station, there is a mechanism to open the lap bars. Even after they are locked, if someone starts having an anxiety attack, thunder, puke, etc. they need to be able to get the people out. Given the way the seats recline and THEN leave, I'm sure there's a locking/unlocking mechanism as well. (I know there is on the B&M's - you can hear it engage, and given the right angle you can actually see the pins lock. I can only assume that the Vekomas would be at least somewhat similar)
Therefore it's conceivable that this unlock button (or even convoluted sequence of several buttons) was pressed either before the train dispatched, or even while the train was dispatching (i.e. "in motion"). When the train is going up the hill, gravity is pulling it down, so the seats won't pop up (they're powered, not spring-loaded). However, centrifugal force while going around an element such as a loop can easily cause the unlocked cars to stand up.
I know of an S&S shot tower at an "undisclosed location" in the US that was almost launched with a restraint open due to a design flaw in the computer system. And I mean wide open as far as it can be open. Fortunately, an alert ride operator caught it and stopped the ride cycle while it was in the weighing stage before it actually launched so no one read about it in the papers. Basically, buttons were pressed in an *exact* order with *precise* timing that caused the ride to think an open seat was closed. Granted, it was big time human error in those buttons being pressed in that order (not your normal sequence of buttons being pressed), but it's also in the way the sensors for closed lap bars were designed coupled with the way the computer sytem reads it that caused it to occur. For confidentiality, I will not say what park. Rest assured that the timeouts were extended that fixed the glitch from even being possible in the future after that. BTW, this happened in 2004. When was the first S&S shot tower built? Long before that... quite a number of years before this -human error- occurred. (At least I'm not aware of any other instances of this occurring)
The article simplifies it as saying "a button was pressed". But I doubt there's a giant "unlock harnesses during the course" button that magically unlocks it which someone accidently hit with their elbow. It's probably more like "if the lock car button is quickly toggled at the exact instance when it's reclined, and then the dispatch button is pressed and held for 5 seconds, and as the train is just about out of the station but still on the last prox sensor to register as being in the station and the toggle switch is hit again, the train will respond by unlocking the cars while leaving the actual harnesses locked as the train goes up the lift, but this leaves them in an unstable state once the train disengages from the lift" -- not your garden variety "oops" by any stretch of the imagination. DISCLAIMER: I totally made that up. I have no insider information regarding this particular incident. Any resemblance to truth is purely coincidental.
It takes me back to my software engineering class in college (and the forum beta thread) -- when you test, there's a limit to how exhaustive your tests can be to be economical, yet catch as many bugs as possible. In the case of the forum, the site may freak out of you constantly click on a link to open/close a profile, but if you have to stand on your head while juggling an apple, a toaster, and a moonpie with your left foot and clicking the mouse with your right foot at a rate of precisely 45 clicks per minute.... even if it's reproducable, is it really WORTH spending the effort to fix?
In the case of a coaster, yes. In the case of a coaster forum, I gotta side with Jeff and say "umm, no" :)
Edit: punctuation/spelling typo
*** Edited 3/22/2007 10:39:45 AM UTC by dannerman***
At the very bottom of an S&S drop tower is a plate that has connectors for the restraint system. It has 1 connector for each restraint. You close 1 restraint, and the sensor will make electrical contact with the plate, and the PLC will change from 'open' to 'closed'. In normal operation, it will not start unless all are closed (showing contact). The funky part is that once the ride starts (it rises up a couple feet to weigh itself) the carriage comes off this sensor plate, and the PLC will show every restraint as 'open', even though it is, in fact, locked. The PLC is programmed to ignore this, since it is normal (just a limitation of the sensor design).
The glitch was that if the lap bar open switch/button was pressed/toggled at the exact right (or wrong!) time, it would allow the restraint to open at the precise time it's beginning the ride cycle by raising the carriage to weigh. Too early and the ride will not start; Too late and the carriage won't receive the unlock signal, and thus the restraints will remain securely locked. If a seatbelt isn't fastened properly, and a person were to push up on the restraint at that precise moment, it would open (because they're not locked) but because it's the part of the ride where it thinks it's supposed to be showing as open (because the contact with the sensor plate is missing). Granted, there's a *LOT* of 'if's in the scenario that shouldn't all happen in the precise order at the precise times -- and were going just fine for years -- but human error allowed it to happen.
If you're programming a PLC, how do you test for that sort of thing? As a software programmer, you generally don't get to pick and choose your sensors -- they're designed by someone else. You take that input, and have to design the ride program accordingly. With a sensor that has a design that only shows it as closed/locked before the ride starts but shows it as open (even though it is actually fully, safely locked) during the ride cycle, there's little else you can do.
I agree it's a poor design -- but it's on the part of the sensor designers -- not the PLC programmers (unless they were the same people ;) )
programmable electronic safety-related systems") SIL 3 (Safety Integrity Level 3) because they use conventional (mini or micro) PLCs or conventional remote I/Os but overall accidents are rare due to the high diagnostic coverage degree (although common mode failures are problematic) and the low (dangerous) failure rate of restraints, especially ASTM category 5 restraints.
Restraint monitoring should be done using methods which allow the detection of accidental cross short-circuits and also use redundant switches with positively opening contacts or safety inductive proximity switches and of course antivalent evaluation, which means that you check not only a condition but also the opposite of that condition, e.g. if you check if a door is closed, you use two separate PLC inputs to assess the condition "Door Closed" as well as the condition "Door Not Closed", this allows a plausibility check by discriminating forbidden combinations after some state transition delay.
Obviously restraint unlocking should not be possible once the status has been validated "All Restraints Locked" by the automation system, and this regardless of any condition. Of course between each step a small delay has to be programmed in order to avoid state uncertainities. Once the carriage starts to move (as the true position detected by sensors or switches, not based on an order issued to move the carriage), indeed even some short delay before the motion starts, no unlock signal shall be issued by the control system.
What you mentioned is a very serious software design flaw (I suppose it's handled by the PLC or SPLC, not by hardware wiring). Also signals can only be evaluated when the slippers (typically spring-loaded contacts) are within a safe range of the contact strips, therefore the position or a train, bogie or carriage has to be monitored with sufficient accuracy.
In any case, the ride operator should be allowed to press wildly any button and the power could fail any moment, it should never allow an unlocking signal to be issued if it could present a risk.
BTW you can still read this scary report about the infamous Therac 25 medical device where several persons were killed due to software errors:
http://sunnyday.mit.edu/papers/therac.pdf
Designing safety controls is very demanding a task and unfortunately many rides are not totally conform. The software and hardware development must both be part of a fully integrated safety approach, they can't be separated. It's extremely important to clearly define what the software has to do and to perform a very thourough risk assessment. Most PLC programmers don't have a strict enough approach to program safety PLCs. When you program a safety PLC you must have a extremely good knowledge of both the electrical equipment of the whole ride (including power supply systems and ancilary support systems), the way it is operated (imagine and anticipate every possible operator error), the other risks and of course the SPLC (safety PLC) itself. Safe programming requires a very high degree of formalism and many constructs which are commly used in PLC applications cannot or at least should not be used.
For example, in some case you use pulse outputs to detect accidental short-circuits but you must also know exactly how to implement the design. Even small details like on which side of a terminal you connect a wire to use in a switch can have an influence on the safety.
Bad are roller coaster automation systems which lose block information and, or, can't update it in real time when the grid power fails. The control system should ALWAYS know in which block a train is even in case of power failure.
Unfortunately it is by far not always the case.
(Edited for typos.)
*** Edited 3/22/2007 4:25:55 PM UTC by Vallean***
That just isn't feasible in software design. No matter how important the system is, there's also a point at which the cost greatly outweighs the benefit.
There were about 8 or 9 conditions that all had to happen precisely in the case of the S&S tower incident. The probability of it happening is apparently 1 in however many shot tower launches there have been worldwide.
When you cross the street, it's customary to look left and right to detect if it's safe. Do you look up? No? Why not? - it's possible a cargo bar door may have fallen off an airplane. The probability of it happening when you cross the street is very low, but it's happened! The reason is because the probability is so low, it's not necessary.
Same thing goes with a ride safety system. Is it necessary to test a sequence of 10 buttons being pressed, along with every possible combination of delays between those buttons? The testing would never end because there's an infinite possibility of combinations.
That may be a little scary to digest in certain applications, but it's the simple truth.
Vallean said:
BTW you can still read this scary report about the infamous Therac 25 medical device where several persons were killed due to software errors:
http://sunnyday.mit.edu/papers/therac.pdf
You wouldn't happen to be a former (or current) MIT course 6er, would you?
Hobbes: "What's the point of attaching a number to everything you do?"
Calvin: "If your numbers go up, it means you're having more fun."
Bolliger/Mabillard for President in '08 NOT Dinn/Summers
@dannerman: It's not that complicated. Safety PLC programs are usually not very complex or at least are structered in a way which allows a very thourough risk analysis. It's just a very restrictive and formal way to program, for example you don't check "every possible operator push-button combination", you just "allow" specific combinations or sequences in specific cases and ignore everything else. When programming safety PLCs you've to follow very strictly all manufacturer's guidelines but when doing so you assume that the Safety PLC *will* behave the way you expect (no side-effects). Conventional PLCs, i.e. non-safety PLCs, don't have an opertaing system verified by a 3rd party like e.g. some German TÜV (the German TÜV is the most respected certification body worldwide, there are several TÜV's and not all German TÜV's are active in the same domains), of course the certification also concerns the PLC hardware, the whole development and manufacturing process as well as the documentation. There are different Safety PLC hardware configurations, most common are dual and triple redundant CPUs (machine and process with normal availability requirement), some are quadruple redundant (more for the process industry where in addition functional redundancy is required too) and very few have a single CPU and only use some sort of "software" redundancy and I wonder how they got approved by the TÜV for IEC 61508 SIL 3 and EN 954 cat. 4.
But I have a question. Has BORG Assimilator gotten any better when it comes to downtimes and it running more frequently. I always remember when I went to Great America, Stealth was usually always closed at some point during the day.
Vallean said:
@ApolloAndy: Not MIT, real world industry engineer.
quote]I just ask because at MIT in one of the entry level comp. sci. classes we did an extensive study of the Therac.
Hobbes: "What's the point of attaching a number to everything you do?"
Calvin: "If your numbers go up, it means you're having more fun."
You must be logged in to post
