Slashdot Mirror
Roller Coaster Data Center
stienman writes "The Top Thrill Dragster at Cedar Point Amusement Park may have more technology than your data center. From the article: "The parameters within which the Dragster has to operate are so finely tuned that variable load weights from people, wind speed and out-side temperature affect its performance. ... After every third launch, the data are averaged and compared with historic launch data in an effort to create that perfect ride - the roller coaster must go fast enough to clear the top of the tower, but slow to between 7 and 15 mph in order to give riders the maximum lift effect at the top."
It's fail safe. In the event of a system failure, it can only fail to launch. Once started, it can stop even if it loses power completely, according to this article.
Define 'fail'. The software is not perfect, the ride still occasionally fails to reach optimal velocity and the riders are shot to the top only to ride backwards down the ascent hill, a rather harrowing experience for riders and obervers who are not aware that its a perfectly normal mode of operation. More importantly, it spends a lot of the time completely disabled, hurting the parks reputation and incidentally costing them lots of money.
The acceleration and braking systems all contain many mechanical fail-safes, the sort that do NOT fail EVER, thanks to superb engineering. Its the same old story, hardware runs forever, if they could only get the dang software right.
I really don't intend to go to that amusement park again though.
Got on the Saturday or Sunday before Labor Day. The park is nearly empty on the Saturday and only a little more crowded on the Sunday.
We would go every year on that weekend and not have any wait over 20 minutes.
Cedar Point, while being the best amusement park in the world, has ruined me for the rest of my life... I cannot go to any other amusement park and enjoy myself like I would at Cedar Point. I have been to several other Cedar Fair parks (Valleyfair, Dorney Park, Michigan's Adventure, etc) but none are even close.
I miss Cedar Point, lines or not. It's their ingenuity in rides that make it amazing. They don't worry about themes and characters and instead worry about thrilling you!
Just out of curiosity, what makes you think you "know" anything about embedded software engineering? Judging from your statements you clearly have no experience with the matter, and you have never spoken with anybody with any experience in the matter.
Most embedded systems are written in either C or assembler and they do just fine. Most real-time OSs are written in either C or assembler and they do just fine. For both of these statements I am including everything from the systems that run on space and planetary probes down to the processor running in the keyboard you were just typing on. I just saw a job posting today for a medical device software engineer requiring experience with WinCE, C++, and C#. Guess what language(s) WinCE was written in. It sure wasn't Pascal, PerfectScript, Perl, PHP, Pict, Pike, Pilot, PL/C, PL/I, Postscript, Prolog, or Python.
Embedded systems don't normally need the absurd amounts of error checking that user level programs do. Thermocouples aren't normally in the habit of randomly generating buffer overflows. Physics is sufficient to deal with most situations, and I'm not just talking about the physics of the real, such as the expected temperature variation over time that said thermocouple would be experiencing. The physics involved in a thermocouple wire breaking will also not overwrite the stack into the code space. I have never heard of a network buffer overflow problem in VxWorks, and that was written in C.
What language would you suggest for embedded systems? Something that will randomly shut down randomly for milliseconds at a time to do garbage collection? Something where the first pass through a section of code takes a radically different different amount of time than the second pass, or the third? Even ladder logic is unsuited to many tasks because the PLCs that are normally used to run it often have loop times dependent on the input states.
C was designed for system level work. It is predictable, which is the single greatest criterion for embedded and real-time systems. It is really quite adequate for the task as long as the people working with it are used to designing embedded systems. Or else they have their work reviewed by those who do have the experience. Any real engineering office would be run this way.