Has the NTSB made a final statement on what the cause was? Or what their findings were?
I don't know of any official statement of their findings. It was also interesting to me that there wasn't anything in the documents that hinted at what they thought the cause was.
I did however find the documents quite interesting to read. some take aways I had after reading most of the stuff:
Pink driver can't really take much of the blame. His work schedule was not out of the ordinary (IOW, not exhausted due to not being acclimated to the schedule or a late shift). He also mentioned that the windows were quite fogged up due to the humidity. With the speed he was going (per instructions) in reverse, combined with the general darkness of the night and the limited visability within the cab, His only real indication of his location was the station lights which he was looking for to get an idea of when he was approaching the station. (monorail was too bouncy at speed to make out many details). He was also coasting when he entered the station because of the expected downhill bump approaching which would've caused the monorail to go overspeed if he was still in gear.
Purple definately deserves some praise for his actions. Guests in the train reported that everything was smooth until the train suddenly started vibrating and skidding. (E-stop). The computer logs were also filled with alarms indicating his attempt to stop the train and start reversing.
Beyond that, it's really hard for someone without any real Monorail experience/knowledge to really make an educated guess at what happened.
The Manager who was offsite was eating dinner at a time when he wasn't expecting to be needed. He had waited until he had helped break down some of the extra setup they had done due to the event crowds and wasn't actively needed for anything at the time he went to dinner. Once he was at the restaurant, the person acting as Central had radio'd him and informed him they were sick and needed to go home. There was another person at the MK station who was trained and able to be Central. The incident occurred while the replacement Central was on their way to the TTC and the office to grab the Central radio. The Manager was covering the radio duties while the replacement person got into place, and could not have gotten back before the replacement was already ready. As for eating offsite, as he mentioned in his interview, It was a readily accepted practice for people to eat offsite at that time of night, especcially since there wasn't much open/available on-site.
The Shop panel operator who was in charge of the switch was also in the process of walking all the monorails coming back into the shop thru the process. He stated he started the switching process, and while it was occuring it looks like he had to walk Silver thru a procedure to override a door alarm so he could complete coming into the shop. As far as he could tell everything looked fine on the system. As for the camera that was on he switch, They only had 1 camera on 8, and 9 was camera free. His training was just to use the camera to verify that a train wasn't on the switch when it was activated, and had seen in the past where the video feed had completely frozen (monitor still showed daylight even though it was night)... so it wasn't trusted to be 100% accurate. The shop personell tended to operate under the assumption that Central who had the same data they had would be a check and balance. (but they had no way of knowing that central wasn't in place).
A couple odd things that showed up. Someone at base radioed about power being down at the station. This is to be expected during a switch operation, so even though it wasn't officially acknowledged, to those who heard the question at Shop and the acting Central, it would appear that the switch operation was going as expected.
The panel which monitors and logs the actual instructions being sent from the switch panel to the switches (an intermediate system) did not record the switch initiation the night of the accident. It did however record all the tests they did post-accident. I did see in the logs a command to return the switches back from the spur to the main lines within the "event window", but to me that seemed a bit odd and out of place. According to the Panel operators, Their system is a simple toggle. They hit a timer button to unlock the system and start a countdown before it auto-locks. once in the system, they deactivate power, and initiate the switch change. I personally didn't see how/why it would attempt to return the switch to the normal position when it was already at the normal position for Pink to get into position to reverse thru it. Though... I may be missing something.
To me personally, I can't say what the root cause of the problem was, and who, if anybody, should shoulder the blame for the accident. Unfortunately, it looked like there were several contributing factors which any one of which not being in play could've prevented the problem. (Central getting sick and the time required to get the replacement from MK to TTC / Shop Panel operator knowing the only monitor they had in place had a tendency to freeze on an image / etc)
Now.... from a disney fan / monorail nut, some of the peeks behind the curtain were interesting. Seeing task checklists, monorail maintenance history, training docs, etc provided a pretty cool look at the operation of the system. It's a real shame that in order to get a peek at that stuff it had to be under such circumstances.
