Overmod This is essentially a continuation of an earlier Euclid post (about a derailment in a sag that was said to have been complicated by dynamic application) which originated in a different discussion about the use of 'heavy dynamic' as an aggravating factor at East Palestine. (I look forward to the promised NTSB report to see what, if anything, they say explicitly about this...)
This is essentially a continuation of an earlier Euclid post (about a derailment in a sag that was said to have been complicated by dynamic application) which originated in a different discussion about the use of 'heavy dynamic' as an aggravating factor at East Palestine. (I look forward to the promised NTSB report to see what, if anything, they say explicitly about this...)
1) Train makeup.
2) Speed.
3) Grade/curvature.
4) Type and axle limitations of the dynamic brake.
5) Amount of slack.
6) Current slack in train.
7) Car types in train.
8) Power configuration including distributed power consists and position in train.
adkrr64 jeffhergert They also will check the download to see what was happening at the time of the incident. If the train was being operated by one of the Energy Management System's auto throttle, then they aren't concerned with any possible train handling deficiency. The computer caused the problem? Well then, nothing to see here. Let's all just move on....
jeffhergert They also will check the download to see what was happening at the time of the incident. If the train was being operated by one of the Energy Management System's auto throttle, then they aren't concerned with any possible train handling deficiency.
The computer caused the problem? Well then, nothing to see here. Let's all just move on....
All kinds of trains can be torn up as long as fuel is being saved.
Actually, I think that the railroads see such "events" as opportunities to provide the feedback necessary to further refine the TO and LEADER software. It's all part of the larger plan to eventually get to crewless operation after a transition period with 1-person crews.
I sympathize with engineers. If they screw up they get "handled" and usually very roughly with time off with no pay. If the computer screws up its an "enlightening learning experience". The duplicity is enough to make even the most even tempered person lose their minds.
adkrr64 Any locomotive in use on a Class 1 will have an event recorder, which will record various data about the operation of the locomotive, including brake system pressures, throttle position, and dynamic brake amperage. Many are programmed to "phone home" when certain events are detected, such as an emergency application or excessive use of power braking. All of that data would be available to management to use while trying to determine the cause of a derailment. While locomotives don't contain sensors to monitor in-train forces, combining the event recorder data with the train make-up information would allow someone to estimate those forces with some degree of accuracy (assuming they know how to do all that math or have a simulator to do it for them).
Any locomotive in use on a Class 1 will have an event recorder, which will record various data about the operation of the locomotive, including brake system pressures, throttle position, and dynamic brake amperage. Many are programmed to "phone home" when certain events are detected, such as an emergency application or excessive use of power braking. All of that data would be available to management to use while trying to determine the cause of a derailment. While locomotives don't contain sensors to monitor in-train forces, combining the event recorder data with the train make-up information would allow someone to estimate those forces with some degree of accuracy (assuming they know how to do all that math or have a simulator to do it for them).
Not only does it record the information, on the modern engines management can remote in to a locomotive in real time. They do our annual check ride in this manner.
After an incident, such as any undesired emergency application, our Operations Command Center (OPCC) calls up the train to check if the air is coming back or the conductor is walking. They also will check the download to see what was happening at the time of the incident. If the train was being operated by one of the Energy Management System's auto throttle, then they aren't concerned with any possible train handling deficiency.
Jeff
The issue is that no monitoring of dynamic application, even one that allows extraction of rate of change of application or release, says anything definitive about in-train forces or momenta. In theory you could get a defective 'first approximation' if you had sufficiently-instrumented "in-train FREDs" as we've discussed as means to reduce service applications in the absence of ECP. You could get an even better approximation from one of the 'on-car instrumentation' solutions being bruited about, if they included some modern version of LVDT measuring draft-gear displacements in realtime with fast communication to the locomotive computer. But any of that is science fiction -- with a very expensive pricetag to implement even with a time-scale of years -- in modern practice.
The obvious Bucky-style short-term 'fix' would be to apply the same kind of 'excitation delay' to dynamic application that GE applies to 'motoring' (in part in order to reduce pollution from accelerating the diesel prime mover 'too quickly'). Ideally this would include some mapping, perhaps "user-selectable" in some way, about how fast the dynamic excitation changes over time vs. what a 'combined power handle' might produce when moved by the engineer to different ranges of dynamic.
That could be thought of as similar to the approach we used in designing the 'freight-compatible' train-control solution for Conrail in the wake of the Chase wreck -- that was originally intended only to modulate the Westinghouse brake 'as a human engineer would' for a given consist, but it was extended to include versions (or in some cases approximations) to 'blended braking' by setting up dynamic for situations short of 'wiped full emergency' stops in nominal minimum distance. You could still implement this, probably in software, without too much conceptual difficulty...
Euclid I found a notice published by BNSF in 2020, which cautions engineers on how to minimize the risk of derailing their trains that comes from improper use of dynamic brakes. It says that the company has had a number of recent derailments that were caused by improper use of dynamic braking. The notice begins with the following: “Engineers making rapid adjustments of dynamic brakes while attempting to slow/control train speed or attempting to stop have contributed to several recent derailments. In all events, the slack was not adequately gathered before advancing to the higher-braking notches therefore causing a severe run-in event and subsequent derailment.” With other brake systems, such as ones on cars and trucks, ships and other heavy equipment, the brake systems only raise the question of whether they will work when needed and whether they can stop in time for emergencies. But train dynamic braking is unique in the number of operational variables that can jeopardize the safety of its use. Since the notice linked here states that there has been a recent increase in derailments caused by improper use of dynamic brakes; I wonder how they can determine that such misuse has occurred. Do locomotives have recorders that document dynamic brake application force, timing, location, etc.? If they do have such recorders, do they also have onboard equipment that can record (or calculate) the buff force generated by dynamic braking throughout the train, and the relative danger that it imposes, if any? I would guess not. But even if they don’t record those forces, can they estimate them based on train weight, consist, and speed; coupled with that actual record of dynamic brake usage? Otherwise, if this caution is supposed to be achieved only by the reckoning of the engineer, it seems like a tall order, as indicated by this BNSF notice.
It's 2024 why wouldn't they be able to monitor and analyze this type of data?
https://lawblet13.org/wp-content/uploads/2022/08/su-2020-02T.pdf
I think this above link will open the notice that is pertinent to this topic.
Engineers 'could' be termed - Professional Slack Adjusters
Slack is the force that Engineers must control in getting today's 10K, 15K and 20K foot trains across their assigned territories. Mishandling of the slack with excessive buff forces or excessive draft forces, in either/or both circumstance damage to the train can happen that may or may not end up in a derailment.
Train handling is a skill that Engineers learn with the seat of their pants with every trip they take across their terrirories. They learn where the slack runs in and where it runs out - with the size trains that are being operated in the 21st Century and the territories the trains are being operated across - a train can have multiple slack actions taking place within it - all at the same time - a run in on the first 50 cars and a run out on the second 50 car and a run in on the third 50 car with the fourth 50 cars 'running free'. The train is operating over multiple grades and dips all at the same time with the slack moving throughout the train as the terrain it is operating over changes.
Never too old to have a happy childhood!
i'm sure that the engineers among us will vouch that knowledge of careful use of the dynamic brake comes with experience, just like careful use of the air.
Our community is FREE to join. To participate you must either login or register for an account.