Murphy SidingCouldn't just chock the wheels with freshly cut tree trunks?
Under current Safety Rules T&E employees are not permitted to chock cars for securement.
Never too old to have a happy childhood!
RDG467 I know I'm taking the risk of getting the *** flying again on this thread, but here's two pertinent facts from page 3 of the NTSB report under the heading 'Accident Narrative': 1. "After the grain train's emergency brake application, the crew began to implement the safety protocols required after an emergency brake application: a crew member immediately broadcast an emergency announcement to other trains in the area, using radio channel 70" <my stop.> 2. In the next paragraph, it reads "However, the oil train did not hear the emergency announcement from the grain train, because they were releasing track warrant authority to the train dispatcher on radio channel 39 assigned to the Jamestown Subdivision. This was in accordance with BNSF operating rules, which state that a train must release a track warrant after it leaves the limits of the warrant. After the train crew made the emergency announcement, the road foreman of engines (on the grain train) attempted to contact the oil train crew by radio to alert them to the emergency brake application. " So, the overlay we heard on the video didn't tell the entire story......
I know I'm taking the risk of getting the *** flying again on this thread, but here's two pertinent facts from page 3 of the NTSB report under the heading 'Accident Narrative':
1. "After the grain train's emergency brake application, the crew began to implement the safety protocols required after an emergency brake application: a crew member immediately broadcast an emergency announcement to other trains in the area, using radio channel 70" <my stop.>
2. In the next paragraph, it reads "However, the oil train did not hear the emergency announcement from the grain train, because they were releasing track warrant authority to the train dispatcher on radio channel 39 assigned to the Jamestown Subdivision. This was in accordance with BNSF operating rules, which state that a train must release a track warrant after it leaves the limits of the warrant. After the train crew made the emergency announcement, the road foreman of engines (on the grain train) attempted to contact the oil train crew by radio to alert them to the emergency brake application. "
So, the overlay we heard on the video didn't tell the entire story......
It would be helpful to have a fully detailed timeline of the events that unfolded ahead of this collision, including an account of who said what and who heard what in the radio transmissions, and the times of these details. Much of it is provided, but there are points of ambiguity.
There is the video, its time clock, the audio of radio transmissions, and displayed captions, including details that are not actually revealed in the events depicted in the video, such as the point of derailment. I assume that was found by inspecting the track damage.
Then there are also the interviews of the two engineers, two conductors and the Road Foreman of Engines. Some, if not all, of these interviews make reference to the sequence of events such as the oil train engineer saying that he dumped the air the instant he first saw the fouling hopper car.
Apparently, the Road Foreman of Engines told the conductor of the grain train to get on the radio and call out “emergency, emergency, emergency” in response to the UDE. This resulted in the message being broadcast after the train had stopped. Soon after, you hear “emergency, emergency, emergency” again in a different voice. I had assumed that this was the oil train engineer repeating the first broadcast as an acknowledgement to the announcement that the grain train had experienced an emergency application. But somewhere in the interviews, it is said that this second announcement was not an acknowledgement of the grain train announcement. Instead, it was the announcement by the oil train engineer that he had made an emergency application.
However, the video captions the point where the oil train went into emergency, and it is 10-15 seconds after the announcement that the oil train had gone into emergency. So there is an unexplained discrepancy there. The video view frame does change during that 10-15-second interval, but the clock counts the elapsed time from the first view to the second, so I assume 10-15 seconds is real time. So, seeing that discrepancy makes me wonder about the whole sequence of events.
EuclidI had assumed that this was the oil train engineer repeating the first broadcast as an acknowledgement to the announcement that the grain train had experienced an emergency application. But somewhere in the interviews, it is said that this second announcement was not an acknowledgement of the grain train announcement. Instead, it was the announcement by the oil train engineer that he had made an emergency application.
Note the earlier post indicating that the oil train was on a different channel when the grain train declared their emergency. The oil train thus never heard the announcement by the grain train. That tidbit very definitely was not conveyed by the video.
Larry Resident Microferroequinologist (at least at my house) Everyone goes home; Safety begins with you My Opinion. Standard Disclaimers Apply. No Expiration Date Come ride the rails with me! There's one thing about humility - the moment you think you've got it, you've lost it...
I would like to see a detailed list that would put all the events in order. Certainly the fact that the oil train never heard the “emergency” announcement that the grain train had derailed explains why the engineer never took any defensive action in response to the warning. The Road Foreman of Engines on the grain train seemed to be surprised that the oil train was not slowing down. But if the oil train engineer never heard the warning, he had no reason to slow down.
The video, while not conveying the full “send and receive” of the radio transmissions, also appears to have a time sequence error regarding the emergency application by the oil train when they saw the obstruction.
Apparently, they have taken down the links to the docket and interviews. I expect the final release of the full report to be coming within a day or so.
tree68 Note the earlier post indicating that the oil train was on a different channel when the grain train declared their emergency. The oil train thus never heard the announcement by the grain train. That tidbit very definitely was not conveyed by the video.
Thanks to Chris / CopCarSS for my avatar.
Murphy Siding tree68 Note the earlier post indicating that the oil train was on a different channel when the grain train declared their emergency. The oil train thus never heard the announcement by the grain train. That tidbit very definitely was not conveyed by the video. Stop it man- you'll ruin the story.
Stop it man- you'll ruin the story.
Don't worry guys. I feel confident Bucky can start a disquisition on the myriad of meanings of "heard."
C&NW, CA&E, MILW, CGW and IC fan
Well yes, it does raise the question of why the emergency transmission was not heard by the most pertinent party. Surely this can’t be just an acceptable outcome of the official radio protocol intended to handle this critical warning message.
But generally, my concern with this topic is the application of the rules if the engineer of the oil train had heard the warning. I have always been interested in Rule 6.23 Emergency Stop or Severe Slack Action, and its earlier iteration, Rule 102 and its connection to Rule 99, both from the Consolidated Code of Operating Rules which stated:
When a train is disabled or stopped suddenly by an emergency application of the air brakes or other causes, a lighted red fusee must be immediately displayed on adjacent tracks at front and rear of train and adjacent tracks as well as tracks of other railroads that are liable to be obstructed must at once be protected in both directions as prescribed by Rule 99, until it is ascertained that they are safe and clear for the movement of trains.
What has always intrigued me about those rules is that they call for immediate protective measures just on the assumption that they may be necessary. They react to just the risk of trouble without actually knowing if there is trouble.
Euc - when you learn how to apply rules in the real world get back to us.
Why bother?
BaltACD Euc - when you learn how to apply rules in the real world get back to us.
I'm sure you meant reality rather than rules.
Norm
Here is a narrated version of the Casselton derailment video. I am not sure who is doing the narration. It may not be the NTSB. But, in any case, the narration adds helpful explanation for those who are watching for the first time.
http://www.valleynewslive.com/content/news/2013-Casselton-oil-train-explosion.html
However, this narrated version does raise a couple questions. The narrator says that each train made an emergency announcement. Accordingly, the video gives the audio of two different announcements from train crews, which indicate that a train has made an emergency application of brakes.
The first announcement comes from the grain train. In his interview, the Road Foreman of Engines talks about telling the conductor to make this announcement, which is broadcast as “Train in emergency.”
Next comes another announcement stating, “Emergency, emergency, emergency,” which is heard prior to the derailment of the oil train. Who made that second announcement?
According to the narrator, the oil train made its emergency announcement after the collision. That would have been when the engineer said “We are everywhere, we are on fire, we are a key train, etc.”
So who made the announcement, “Emergency, emergency, emergency” heard before the derailment?
EuclidThe first announcement comes from the grain train. In his interview, the Road Foreman of Engines talks about telling the conductor to make this announcement, which is broadcast as “Train in emergency.” Next comes another announcement stating, “Emergency, emergency, emergency,” which is heard prior to the derailment of the oil train. Who made that second announcement?
This has gone on long enough.
The "Emergency, emergency, emergency" is clearly from the same person on the grain train who made the 'train in emergency' call; he realizes he has not followed the "correct" form of the call and proceeds to follow the rule in a somewhat desultory tone.
We should remember that according to the testimony, the grain train was already braking to let someone off, which was given as a reason why the occurrence of the UDE was recognized late. I did not see the NTSB ask the specific question about whether a perhaps unexpectedly 'normal' deceleration in snow/ice conditions shoulda-woulda-coulda set off alarm bells for the crew; perhaps the matter will come up later as we all know 20/20 hindsight is so accurate retroactively in pending emergencies. Please let's not belabor it here.
The only remaining 'what if' in this situation is, if there had been a Canadian-style tone alert on detection of the grain train's actual UDE, (1) how long would it have taken for the alert to be 'processed' to the point the key train applied its own brakes; (2) what type of braking -- full-service or emergency -- would rules have called for in such conditions; and (3) how long would subsequent physics ... use the curves in the one-pipe vs. ECP comparison if you don't want to argue about math ... say it would take to stop the train, and how fast would it have been moving at the time it encountered the hopper.
There won't be any magic here. I doubt that the reaction to a radio UDE tone would ever be for every engineer hearing it, near or distant, to instantly plug their train; it would be handled through the equivalent of a RTC or dispatcher, with human reaction times and communications channels, and instructions relayed to affected trains. Conversely, a dispatcher couldn't see the blowing snow, which was a major factor here, so almost certainly his order to a loaded oil train passing another train would be to brake safely in some service position.
A derailment detector or other instrumentation would have provided some extra seconds of warning -- we can, and probably will, debate ad nauseam on exactly how many. Then we could rehash how the oil-train crew 'could' have responded to the earlier warning, but this would still involve first the notification procedure and then the reasoned response in context.
What is missing from all the spasms in this thread is what can practically be done, either by railroads or the FRA, to reduce either the likelihood or the magnitude of accidents like this in the future.
RME- How would a derailment detector work?
Murphy Siding RME- How would a derailment detector work?
It would have detected the initial derailment of the grain train, and set the brakes at that point. Evidence suggests that this derailment began a derailed-dragging phase that persisted for some considerable distance before the cars began piling up and ultimately fouled the other track.
There may have been time during the derailed-dragging phase to brake the train sufficiently to prevent a pileup; if a derailment detector began braking as soon as the derailment happened. If there was no fouling during the derailed-dragging phase, and if the train did not ultimately pile up and foul, the oil train would have passed without colliding with anything.
Current derailment detectors make an emergency application the instant that the first wheelset leaves the rail. If the train immediately begins to pile up at that point, the derailment detector offers little benefit. But for derailments that begin with a derailed-dragging phase, a derailment detector can prevent a pileup.
EuclidMurphy Siding RME- How would a derailment detector work? It would have detected the initial derailment of the grain train, and set the brakes at that point.
I'm still with Murphy Siding. How would a derailment detector work? Do we have to retrofit each and every railcar with 8 video cameras and a PC to monitor the position of the wheels? Not gonna happen.
Murphy SidingRME- How would a derailment detector work?
At the risk of making you plow back through other Buclidean threads, we discussed some of the alternative technologies at length -- great and exhaustive length -- in some of the posts on differential braking and the like.
The current Spanish device which triggers an emergency application when the truck yaws beyond a certain point could easily be equipped with contacts or a simple pull-out arrangement that would trigger the rail equivalent of an ELT. This in fact could probably be arranged to 'squawk' information about the particular car involved, or even some event-recorder-like information starting with the last few seconds before the triggering occurred, and then streaming information like the attitude or momentum or vibration of the car (easily deduced from the angle and position of the attached transponder via cheap accelerometer cores)
Another approach involves instrumenting parts of the trucks themselves to detect aspects of 'derailed-car behavior' -- I'm currently under NDA on this technology but it is becoming highly refined and relatively cost-effective.
I think extending WILD coverage to give shorter intervals between detector stations is highly valuable, and until there is fairly widespread installation of on-car detectors (not likely unless and until mandated - and incomplete until substantial buildout is achieved) it's the default standard. However, that approach can't ensure that every derailment would be caught before an incident or accident ensues. We could speculate on whether a WILD would be installed near the location the signal maintainer was 'working' (since the communications, cabinets, etc. would be easily provided for it there) BUT it would seem that an alarm from a device in that location would have given very short warning in this particular case. I think installing more WILDs is certainly worth doing, and keeping after individual car detectors are in place.
If we assume data-network integrity of the kind required for PTC, the provision of effective onboard derailment detection and warning via a modulated tone should be relatively easy to provide (especially if Meteorcomm has done their job right with the implementation of SBRs).
[EDIT - note that I did not mention dragging-equipment detectors. Those are certainly useful, but no one sane would consider them as standing in for critical derailment detectors.]
DS4-4-1000 Euclid Murphy Siding RME- How would a derailment detector work? It would have detected the initial derailment of the grain train, and set the brakes at that point. I'm still with Murphy Siding. How would a derailment detector work? Do we have to retrofit each and every railcar with 8 video cameras and a PC to monitor the position of the wheels? Not gonna happen.
Euclid Murphy Siding RME- How would a derailment detector work? It would have detected the initial derailment of the grain train, and set the brakes at that point.
Just to clarify, I am referring to derailment detectors or sensors that are mounted on the freight cars, as opposed to a lineside device.
The key point is that while a derailed-dragging condition indicates the start of an emergency; without a derailment detector, there will be no application of brakes unless the crew sees the derailed car dragging and makes the brake application. Once a pileup begins, the air hoses part and the train automatically goes into emergency. But the nature of a derailed-dragging phase is that no air hoses part, and so no brake application is automatically made. So the derailment detector senses the derailment involved in the dragging, and makes a brake application.
There are various technologies invovled with derailment detectors, and they do monitor evey wheelset. Some are purely mechanical-pneumatic. Of course the industry will resist the use of derailment detectors. But they are being adoped in other countries such as India.
On-car derailment detectors will occur when either they become economically desireable (probably never) or they are mandated (which would look a lot like the implementation of PTC).
Like the infamous Ford Pinto - as long as it is cheaper to pay for the occasional derailment, there's no real reason to install such detectors on every single car.
There are derailments every day. Most occur at low speeds. Incidents such as this one are very, very rare.
DS4-4-1000Do we have to retrofit each and every railcar with 8 video cameras and a PC to monitor the position of the wheels?
Oddly enough, if the '8 video cameras' use current cell-phone camera cores, and the 'PC' is a modified low-power PLC-like device running machine-vision software, that's a cheap and easy way to monitor the relative position of the wheel tread and rail positions (not as a video image, but a comparison of reflected bright spots with a structured light source). Note where the cameras and structured-light sources on a typical three-piece truck frame would go, and how power and data flows would be provided there.
In my opinion, this approach has some problems, particularly including grime buildup, which makes it relatively unfavorable as a critical derailment detector. It would, however, serve nicely to detect other things, like potential flange breakage or tread scarring, should there be perceived value in being able to look for such things in realtime or for automated analysis.
RME DS4-4-1000 Oddly enough, if the '8 video cameras' use current cell-phone camera cores, and the 'PC' is a modified low-power PLC-like device running machine-vision software, that's a cheap and easy way to monitor the relative position of the wheel tread and rail positions (not as a video image, but a comparison of reflected bright spots with a structured light source). Note where the cameras and structured-light sources on a typical three-piece truck frame would go, and how power and data flows would be provided there. In my opinion, this approach has some problems, particularly including grime buildup, which makes it relatively unfavorable as a critical derailment detector. It would, however, serve nicely to detect other things, like potential flange breakage or tread scarring, should there be perceived value in being able to look for such things in realtime or for automated analysis.
DS4-4-1000
I am sure the Car Department would love replacing and documenting 800 devices every 1000 mile inspection.
BaltACDI am sure the Car Department would love replacing and documenting 800 devices every 1000 mile inspection.
They'd likely be permanently bonded to the sideframes and run continuously (an advantage of extremely-low-current electronics and 'harvested power' sources) so all the car department would do would be run a canned test-and-exercise routine on the devices. Any problem or issue, like damaged or obscured objective lenses, would have been apparent from the datastream long before the date and time of the car inspection, and 'time and parts' allocated for any such work reasonably far in advance.
The setup I designed had full specifications for jigs that were applied to any sideframe to simplify removal and deployment bonding of the devices in correct alignment, etc. No more specialized training needed than for making field splices in communications glass fiber with one of the automatic kits (my daughter when four could both do the splice and test the result without particular difficulty...)
What I was far more concerned with was the analogue for wheels of the result Strasburg had when they first started testing boilers with ultrasonic NDT -- they didn't call it the 'death ray' for nothing! It is possible that the system will detect many more early defects than expected, and there's no guarantee that a 'factor of safety' erring on the side of false positives might be overcompensatory for some types of damage (such as small flatting that has started producing shelling or other progressive defect) that are currently deferred by 1000-mile inspections.
Power would be the issue - and a solar solution (more $$$) would probably handle it most of the time.
I suppose it would be possible to passively download each car, at least an "error" report. Depending on how much data there was to pass, it might be possible at a yard. Our local utility reads meters at pretty much highway speeds, unless the meter is a distance off the road.
All of the data (either downloaded from the car or from a camera that's been swapped out) will require manhours to analyze.
But that's still after-the-fact. A derailment detector has to work in real-time. Perhaps sending out a burst to the EOT receiver with car number and some form of code would help - but only in a dragging incident. If the car digs in immediately, the information has virtually no value, except as an investigation tool.
tree68All of the data (either downloaded from the car or from a camera that's been swapped out) will require manhours to analyze.
This application is one of the poster children for expert-system artificial intelligence and machine vision.
And the cameras are fixed and potted to the sideframes -- not coming off unless known defective. Not necessarily bigger, with local processing and power storage, than half an M&M.
What provides the 'derailment detection' here is the loss of running relationship between the bright patch from the wheeltread and the bright patch from the railhead. Naturally you have to discriminate what happens when the wheel runs over frogs or hits leaves that have been hardened into the usual dark plastic-like mass -- this is a major reason why fast-acting machine-vision systems at low enough cost haven't been deployed yet (they are just now coming into use on high-speed track-inspection systems)
There's a surprisingly large amount of pre-processing that can be done very fast in modern logic, to recognize common causes of "LOS" and deal with it appropriately. At least some of this recognizes that the correct response to what looks like a derailment is NOT to promptly plug the train in all cases; while the response for, say, a differential-braking setup may be complex, the command signals and subsequent monitoring (and fault workaround, etc.) are comparatively easy to define and implement. The fun will come in when different vendors try implementing proprietary technology that supposedly works to common open standards.
Where do you get a bright patch at night or in a tunnel or in water?
Dave H. Painted side goes up. My website : wnbranch.com
dehusman Where do you get a bright patch at night or in a tunnel or in water?
Or protect said camera from the water spray, dust, mud, and other gunk that gets thrown up from the wheels?
It's been fun. But it isn't much fun anymore. Signing off for now.
The opinions expressed here represent my own and not those of my employer, any other railroad, company, or person.t fun any
zugmann dehusman Where do you get a bright patch at night or in a tunnel or in water? Or protect said camera from the water spray, dust, mud, and other gunk that gets thrown up from the wheels?
In curve territory there are a lot of 'greasers' - grease and optics go well together. NOT!
RME Murphy Siding RME- How would a derailment detector work? At the risk of making you plow back through other Buclidean threads, we discussed some of the alternative technologies at length -- great and exhaustive length -- in some of the posts on differential braking and the like............
At the risk of making you plow back through other Buclidean threads, we discussed some of the alternative technologies at length -- great and exhaustive length -- in some of the posts on differential braking and the like............
RME tree68 All of the data (either downloaded from the car or from a camera that's been swapped out) will require manhours to analyze. Erik, you know better than that -- this application is one of the poster children for expert-system artificial intelligence and machine vision.
tree68 All of the data (either downloaded from the car or from a camera that's been swapped out) will require manhours to analyze.
Erik, you know better than that -- this application is one of the poster children for expert-system artificial intelligence and machine vision.
I think Tree68's name is Larry....
I would certainly know betterthan that, having heard about GE's work on machine vision some 10 years ago.
I've also heard enough over the years about industrial wireless sensors and various forms of energy harvesting to think that there are a fair number of non-video means of instrumenting a truck. Accelerometers and MEMs gyros can be quite cheap as long as you don't need INS accuracy. I would suspect that the easiest way to harvest energy would be from vibration and a small low cost capacitor could store enough energy to get a useful signal out.
- Erik
Murphy SidingI believe I'd prefer a root canal to that scenario.
AMEN!
BaltACD zugmann dehusman Where do you get a bright patch at night or in a tunnel or in water? Or protect said camera from the water spray, dust, mud, and other gunk that gets thrown up from the wheels? In curve territory there are a lot of 'greasers' - grease and optics go well together. NOT!
What part of 'that's why I discarded the optical approach early' is still unclear to readers of this thread?
(The 'structured light source' of course would be designed to work under both strong ambient light and in the dark; you'd use a simple IR illumination (like the approach in a "0 lux night shot" video camera) otherwise. For nitpickers: obviously using IR only at night and visible spectra in daytime...)
Our community is FREE to join. To participate you must either login or register for an account.