dehusman Euclid When I refer to placing the leading cars under tension to pull on the derailing cars, I am not saying that this will be an extraordinary high amount of pulling force. The tension that I am referring to would only function as a kind of preload tension ahead of the derailed cars to keep them from becoming an obstacle to the trailing cars pushing forward with their kinetic energy. What are going to do going downhill? The train will be using dynamic brakes which means it will be in compression. How are you going to create this tension and still stop the train going downhill?
Euclid When I refer to placing the leading cars under tension to pull on the derailing cars, I am not saying that this will be an extraordinary high amount of pulling force. The tension that I am referring to would only function as a kind of preload tension ahead of the derailed cars to keep them from becoming an obstacle to the trailing cars pushing forward with their kinetic energy.
When I refer to placing the leading cars under tension to pull on the derailing cars, I am not saying that this will be an extraordinary high amount of pulling force. The tension that I am referring to would only function as a kind of preload tension ahead of the derailed cars to keep them from becoming an obstacle to the trailing cars pushing forward with their kinetic energy.
What are going to do going downhill? The train will be using dynamic brakes which means it will be in compression. How are you going to create this tension and still stop the train going downhill?
If my system activated upon the occurrence of a derailment while the train was in dynamic braking, the system would have to take the engines out of dynamic braking. At the same time, it would apply considerable ECP braking to the cars behind the derailment; and somewhat less ECP braking to the cars ahead of the derailment. This differential braking would stretch the train, and focus that stretch on the cars involved in the derailing process.
Sounds like you have described a "well car" with disc brakes.
midwest member Sounds like you have described a "well car" with disc brakes.
Disc brakes are relatively difficult to implement on a three-piece truck. What he's basically talking about with ECP is electronic proportional control of the actual braking effort, moment to moment, rather than the existing system where actuation is (analog) proportional, but release is not.
Theoretically it is not much more difficult to implement proportional tread braking, even on three-piece trucks that use floating brake beams and long rods and levers. If you keep the existing foundation, it greatly reduces the potential cost of the swap to a safer brake system (and the interworkability of an ECP car with those equipped only with 'legacy' air brake).
Even in unit trains of the type Euclid is suggesting, retaining much of the current type of brake gear is likely to be a sensible approach costwise, particularly where maintenance and adjustment is concerned.
There are two added 'inputs' to the differential-braking system: the computer must know the position of the shoe relative to the tread, and the slack adjustment has to be tracked. I suspect there will be some device that quickly takes up all slack in the gear while applying no more than a few pounds of actual retarding force when the 'derailment' system is first actuated; all the follow-on brake modulation would use that position as a baseline.
Overmod,
My intention is to retain the conventional brake rigging foundation, brake beams, and wheel tread brakes as currently used on tank cars. I would only revise the components as necessary to convert from conventional pneumatically controlled air brakes to electronically controlled air brakes or “ECP brakes.”
The operation would simply apply and release air pressure to the air brake cylinder. I am thinking about the basis for your points about the computer needing to know the position of the shoe relative to the tread, and the computer needing to track slack adjustment.
I believe this brake shoe slack would close up quite fast even with a small amount of air pressure if that pressure could be built up quickly in the airbrake cylinder. So, if the intent were to build only a small pressure preliminarily, that would best be accomplished by a very quick shot of air at a high flow, which would abruptly cut off. This shot may only last for a tenth of a second, for example.
That action would take the slack out of the brake linkage and set the shoes against the wheels. Then those brakes would be staged for instant braking effect once the airbrake cylinder pressure is increased. So I guess that staged position would be the “baseline” that you refer to.
This effect of staging the brakes with only a very small brake cylinder pressure would typically be executed only on the cars ahead of the derailment, and only to the extent that there are relatively fewer cars ahead of the derailment than behind. If for instance, there were 20 cars ahead of the derailment and 80 cars behind it, the 20 cars would be staged with brake shoe slack removed. The brakes on the 80 cars behind the derailment would immediately begin a heavy application in order to stop the train.
But this heavy application would not go to full pressure instantly. It would apply to all cars behind the derailment at the same time, but the pressure would build in a progressive “ramp-up” in order to prevent a sudden tensile shock into the derailing cars and the cars still on the rails ahead of the derailing cars. This progressive ramp-up would prevent that tensile shock from breaking the train in two, either in the derailed cars, or the cars ahead of the derailment. The ramp-up might last for say ten seconds, for example.
If there were 80 cars ahead of the derailment and 20 cars behind it, there would be no preliminary staging of the brake shoes to remove their slack. The brakes on both sections would immediately go to heavy application, but with less application to the brakes on the 80 cars ahead of the derailment than on the 20 cars behind it. Some ramp-up for the application to each section of cars might be advisable, but this needs to be analyzed for the design of the program, and I would expect it to vary according to the ratio of cars ahead of and behind the derailment. It would also vary according to other conditions such as train speed and location on the line.
Euclid, I approve completely of each car being a smart car with evaluation of the exact situation, with respect to what it is doing, where it is, and what the adjacent cars are doing. Then, if proportional braking is the safest measure at the time, that is what will happen. If the fastest braking is the safest measure at the, that is what will happen. I am unsure how long such a development will take, and I think my approach is a good interem step.
Lets look at some known facts.
1. Computers in Automobiles can sense and execute commands at Thousands per second. An example is the solenoids in the valve body of your automatic transmissions. This means having each Train car a "smart" car is inevitable.
2. Sensors on wheels/rotors, gears, is easy and cheap. In this case we do NOT want to STOP the wheels during any braking, we want to slow them down. A slipping wheel slows down a train car LESS than a wheel with some traction.
3. This should be heading in an ABS direction then, keep the wheels behind a derail in anti lock but heavy brake mode.
4. Switching brakes ( Engineer /the Engine) takes a lot of time
5. Magnetic Brakes.. The required Power to run them effectively in the heavyweight class would be just way expensive and would be needed per car. I also seem to recall problems with "Rust" on these units. A great idea though, and was used in the highway industry and still is in some areas.
6 ENERGY. Its been mentioned a bunch in this thread, but No real solutions to all the energy that's pushing a moving train. Its really hard to figure all the outcomes as its not as simple as Force in ONE direction. Many derails happen on curves, and the forces will just want to move on Straight ahead. No Draw bar or chain will stop that. Brakes, EPC, antilock, ABS, None will stop or even slow a 45 mph oil train down enough to prevent a Pile up.
To make this EPC, brake sensing, or even ABS system work, while computer controlled, it will need Help Absorbing lots of force. The ONLY way this can happen is with a "EAC" Energy Absorption Car", or a few per consist. These would have to be as long as an Oil car and have the capability to absorb shock and pressure, with air, hydraulic shocks/ etc.They may have a different truck system with more braking abilities than a normal tank car as well. Also, equipped as a "smart car" it would be able to measure and report the forces for future use in construction, like a Dynamometer car has been doing for over many decades. This is NOT a "buffer" car as they are used/called today.
ALL of the above technology is being done today in many forms, its not new.
I'm surprised there hasn't been any comment on the agreement reached between the AAR and DOT on the operation of CBR trains.
Dave H. Painted side goes up. My website : wnbranch.com
BNSF has taken the leap and with Greenbrier is designing a new tank car. With all the bells and whistles that has been suggested in this blog there has been little to no discussion about one important item-- the center of gravity. As far as slosh in a retangular container in concerned---that's what baffels are far. It will be interesting to see what Greenbrier dreams up and how it test at Pubelo.
This safer oil train concept that I am proposing uses electronically controlled pneumatic (ECP) brakes which are currently used in specialized railroad applications. For the most part, ECP brakes are fully developed, and are preferred over conventional automatic air brakes, but the universal conversion is still a long way off due to the need for 100% commitment to that conversion and the cost of doing that.
However, what I am proposing is using ECP brakes only on specialized oil trains operating as unit trains composed of captive rolling stock. Then I am adding a new feature to the standard ECP brake system for the purpose of mitigating the crushing damage caused during a derailment.
As far as I know, nobody else has proposed extending the ECP brake concept into the sort of derailment control function that I am proposing here, but the extension falls naturally into the basic operation and attributes of ECP brake systems.
In the most fundamental sense, my concept proposal requires that the ECP brakes can communicate with, and control the brakes on each car independently, so braking power can be varied from car to car within the train. As far as I know, this is not a normal requirement with ECP brakes, so they are not equipped with this functional ability. They apply braking to every car in the train as a whole, and if braking force is to be varied, all cars remain synchronized to that variation. So the ECP system does not need to identify individual cars within the train. It treats them all the same.
However, the ECP braking that I am proposing for derailment control must be able to identify individual cars in the train in order to create the necessary differing patterns of brake application. The way to accomplish this is to simply assign each car an identification number that can be read by the ECP brain in the controller on board the locomotive. Then the brain can detect the locational order of these identification numbers from one end of the communication cable to the other.
Therefore, you could assemble any of the cars in any random sequence, and the ECP controller would know where they are in the train. That way, when a derailment occurs with say car number 44678895, the controller will know the identification and order of all the cars ahead of the derailed car and of the cars behind it. Therefore, the controller will be able to vary the braking force applied to those two separate ranges of cars for the purpose of stabilizing the derailment action the instant it begins.
Euclid, Go ahead and take credit for your version of the ECP. Smart train cars make sense. You have repeated your "IDEA" many many times. Rarely, if at all, in the real world, do Ideas, as thought up, get implemented. Beating it to death here will not work. Your system lacks in dynamics other than straight ahead. ..Pile ups, which you are trying to avoid, can only be avoided when some excess energy is absorbed. Tougher cars, Draw bars,lower CG, isn't addressing the ENERGY at hand. ECM's currently in use can do the "ECP" job with sensors on the cars. Bigger braking surfaces can help, but brakes are only going to capture about 1/50th of the moving force in a 30 unit train. ECP or not the Loaded energy is too great without suitable absorption. Compressible, energy absorbing, superbly equipped braking Dynamometer cars, with heat exchangers on board is the only viable solution for the energy. These could work with a system of YOUR mention. Having done some experiments with this, on scale, I can assure you the brakes and the friction surface they encompass on the track, are NOT good enough. Fast response can help , but not enough. Possibly, the Energy absorbing car could "carry" extra trucks which could be deployed in an instant to help braking.. This problem will take a BUNCH heads, Half fixing it, its going to fly in the RR world, not with the press looking for blood these days.
Euclid In the most fundamental sense, my concept proposal requires that the ECP brakes can communicate with, and control the brakes on each car independently, so braking power can be varied from car to car within the train. As far as I know, this is not a normal requirement with ECP brakes, so they are not equipped with this functional ability. They apply braking to every car in the train as a whole, and if braking force is to be varied, all cars remain synchronized to that variation. So the ECP system does not need to identify individual cars within the train. It treats them all the same.
"Basic" ECP will have a control input from load cells in the trucks or bolsters, controlling the brake application relative to the car weight. This gets around having to use any kind of decelakron/decelostat system to modulate deceleration, pick up speed from an axle, etc. as would be done for passenger cars.
As a result, the braking integrity does not depend on where in the train a given car is located. And it may not be necessary to integrate the car-order report for a given train with the brake control algorithm (as would currently get the job done in contemporary railroading without a complex protocol for determining the physical locations of the cars...).
However, the ECP braking that I am proposing for derailment control must be able to identify individual cars in the train in order to create the necessary differing patterns of brake application.
And this is precisely what requires positional determination. One way to accomplish this in a pure distributed system is to have an ID on the car, and have any adjacent car capable of reading this ID and understanding that the ID is its 'neighbor' at one end.
Then when the computer polls the consist, it gets 'ordered triplets' of IDs and can compile a train order from these data without any need for sequential reading or trying to get positions via, say, embedded NDGPS (which can actually do the trick most of the time, and is a useful 'check' when it's working, but shouldn't be relied on as an absolute reference...)
The way to accomplish this is to simply assign each car an identification number that can be read by the ECP brain in the controller on board the locomotive. Then the brain can detect the locational order of these identification numbers from one end of the communication cable to the other. Therefore, you could assemble any of the cars in any random sequence, and the ECP controller would know where they are in the train. You would have to do an explicit 'scan' of the bus, but how does the 'brain' know which address is located where? The physical cable is only the minimum number of conductors to implement something like CANbus, and probably nothing more intricate that twisted-pair for each direction of backbone. Time-of-flight might work, but you would need something like a built-in TDR across multiple, uncertain-quality physical connections, and that's not likely to be workable in the long term, even if it could be made to work under lab conditions. As noted, you could do data fusion with the manifest or consist, which would give you the positions of the car numbers (and thence allow reference to the IDs) in the train. But if there is a mistake, GIGO (and that is NOT a desirable mode for a safety-critical system!) As I recommended, if you have multiple vibration monitors on the trucks, use those as the reference IDs, with some method of determining which wheel on the car gets which ID (it will change with the truck frames, as the monitors are incorporated on them), and then have each car interrogate its neighbor 'periodically' and keep comparing the result in order to derive the positional aggregate. (You can always arrange to check it against the manifest order, if you're nine-nines paranoid about critical data integrity...) That way, when a derailment occurs with say car number 44678895, the controller will know the identification and order of all the cars ahead of the derailed car and of the cars behind it. Therefore, the controller will be able to vary the braking force applied to those two separate ranges of cars for the purpose of stabilizing the derailment action the instant it begins. Which is precisely the differential braking that we've been talking about all this time. One thing that I think could be gainfully added is a small strain-gage-like sensor that reads buff and draft for each end of the car. (You need to know 'car end' to resolve the eight vibration modules correctly in train, so nothing is necessarily added by having an A and a B end, and the controller doesn't care whether the A or B end is leading on any particular day...) This gives a direct reading on the tension between cars, either as a backstop for the positional information or as a control input for the proportional braking. (It will also help with a variety of other operational issues, for example management of the node in DPU operations...) There is nothing new in modulating ECP proportionally on a car-by-car basis; the novelty is entirely in using the braking to keep sensitive and proportional tension across a putatively derailed car... or, for that matter, across what may be multiple 'islands' of derailed cars as the train decelerates, or to manage the situation if there is a break-in-two so the rear end doesn't collide with the front (now you see a critical reason I want to make the network like a wireless PAN instead of relying on cable continuity in the consist?)
The way to accomplish this is to simply assign each car an identification number that can be read by the ECP brain in the controller on board the locomotive. Then the brain can detect the locational order of these identification numbers from one end of the communication cable to the other. Therefore, you could assemble any of the cars in any random sequence, and the ECP controller would know where they are in the train.
You would have to do an explicit 'scan' of the bus, but how does the 'brain' know which address is located where? The physical cable is only the minimum number of conductors to implement something like CANbus, and probably nothing more intricate that twisted-pair for each direction of backbone. Time-of-flight might work, but you would need something like a built-in TDR across multiple, uncertain-quality physical connections, and that's not likely to be workable in the long term, even if it could be made to work under lab conditions.
As noted, you could do data fusion with the manifest or consist, which would give you the positions of the car numbers (and thence allow reference to the IDs) in the train. But if there is a mistake, GIGO (and that is NOT a desirable mode for a safety-critical system!)
As I recommended, if you have multiple vibration monitors on the trucks, use those as the reference IDs, with some method of determining which wheel on the car gets which ID (it will change with the truck frames, as the monitors are incorporated on them), and then have each car interrogate its neighbor 'periodically' and keep comparing the result in order to derive the positional aggregate. (You can always arrange to check it against the manifest order, if you're nine-nines paranoid about critical data integrity...)
That way, when a derailment occurs with say car number 44678895, the controller will know the identification and order of all the cars ahead of the derailed car and of the cars behind it. Therefore, the controller will be able to vary the braking force applied to those two separate ranges of cars for the purpose of stabilizing the derailment action the instant it begins.
Which is precisely the differential braking that we've been talking about all this time.
One thing that I think could be gainfully added is a small strain-gage-like sensor that reads buff and draft for each end of the car. (You need to know 'car end' to resolve the eight vibration modules correctly in train, so nothing is necessarily added by having an A and a B end, and the controller doesn't care whether the A or B end is leading on any particular day...) This gives a direct reading on the tension between cars, either as a backstop for the positional information or as a control input for the proportional braking. (It will also help with a variety of other operational issues, for example management of the node in DPU operations...)
There is nothing new in modulating ECP proportionally on a car-by-car basis; the novelty is entirely in using the braking to keep sensitive and proportional tension across a putatively derailed car... or, for that matter, across what may be multiple 'islands' of derailed cars as the train decelerates, or to manage the situation if there is a break-in-two so the rear end doesn't collide with the front (now you see a critical reason I want to make the network like a wireless PAN instead of relying on cable continuity in the consist?)
In cx territory it would first have to start with the massive replacement of almost every bridge that wa built around the beginning of the 1900 s before you could even beging to even think of doing something like that. Almost evry bridge in the phila baltimore area that I know of wa built around that time and has yet to be replaced
matthew.brandleyIn cx territory it would first have to start with the massive replacement of almost every bridge that wa built around the beginning of the 1900 s before you could even beging to even think of doing something like that. Almost evry bridge in the phila baltimore area that I know of wa built around that time and has yet to be replaced
His differential brakes are no more hard on bridges (or other civil) than any alternative, particularly ballasted-deck bridges. The actual braking effort to achieve the differential action is less, not more, than a conventional emergency-brake actuation, although it is possible that very short periods of actuation would be stronger at a given time during an ECP braking event than their conventional counterparts at the same time in the braking run.
I think the concern is with the additional weight of the 'safe' unit train, and it might be sensible at this point to provide a precise Cooper loading for a loaded oil train using this system -- I'd be surprised to find it that much higher than, say, a conventional HAL stack train as to justify massive ROW and infrastructure improvements.
Not that I'm against checking and rebuilding 100-year-old assets on a regular basis!
Overmod His differential brakes are no more hard on bridges (or other civil) than any alternative, particularly ballasted-deck bridges.
His differential brakes are no more hard on bridges (or other civil) than any alternative, particularly ballasted-deck bridges.
Since his plan calls for braking less than emergency, it will be less than a conventional train (which of course means stopping distances will be longer)
I think the concern is with the additional weight of the 'safe' unit train, ...
There is no additional weight, the cars are limited to either 263,000 or 286,000 lbs. so if you increase the weight of the car you limit the capacity (more car = less oil) . But in any case the weight of the car has an upper bound.
BARFlyer Euclid, Go ahead and take credit for your version of the ECP. Smart train cars make sense. You have repeated your "IDEA" many many times. Rarely, if at all, in the real world, do Ideas, as thought up, get implemented. Beating it to death here will not work. Your system lacks in dynamics other than straight ahead. ..Pile ups, which you are trying to avoid, can only be avoided when some excess energy is absorbed. Tougher cars, Draw bars,lower CG, isn't addressing the ENERGY at hand. ECM's currently in use can do the "ECP" job with sensors on the cars. Bigger braking surfaces can help, but brakes are only going to capture about 1/50th of the moving force in a 30 unit train. ECP or not the Loaded energy is too great without suitable absorption. Compressible, energy absorbing, superbly equipped braking Dynamometer cars, with heat exchangers on board is the only viable solution for the energy. These could work with a system of YOUR mention. Having done some experiments with this, on scale, I can assure you the brakes and the friction surface they encompass on the track, are NOT good enough. Fast response can help , but not enough. Possibly, the Energy absorbing car could "carry" extra trucks which could be deployed in an instant to help braking.. This problem will take a BUNCH heads, Half fixing it, its going to fly in the RR world, not with the press looking for blood these days.
BARFlyer,
You might be confusing my proposal with Dave Klepper’s proposal since that has been discussed extensively in this thread. I am not trying to dissipate the kinetic energy of the train as quickly as possible, as Dave intends. So, contrary to your interpretation of what I am proposing, it is indeed my precise intent to address “the ENERGY as hand,” as you say.
But the way I address it is not to dissipate the energy faster than it normally dissipates. The way I address it is to control the energy so it does not get dissipated by crushing tank cars.
Euclid, you want to stop the accordion Pile ups on a derailment, no?
1. you will NEED more than brakes , bars and a ECP
2. Do ANY of you know how a tiny "Smart" Car got passed the crash tests? It simply transferred the energy by ROLLING away from the impact scene.
3. Knowing which car has derailed in an instant. Magnets on inside of wheels, with sensors on the trucks. In other applications these are flush mounted. Sensor pointed at inside of rail can tell if car truck isnt located correctly side to side. These would be checked thousands of times per second, like they are now in a typical ABS brake system in a car..INSTANT detection of wayward truck is possible.
4. After detection.. slowing the train, while keeping tension, or upright, is ONLY possible IF there is enough Braking available BEHIND the derail, and enough extra energy Absorbed in FRONT of the derail. Even still, the amount of energy, MOMENTUM, would overcome ANY Braking system ( the mechanical parts of any system) Slowing only 1/50th of the mass will not stop an accordion pile up
5. Euclid >QUOTE" But the way I address it is not to dissipate the energy faster than it normally dissipates. The way I address it is to control the energy so it does not get dissipated by crushing tank cars. " <, End Quote.
That is TOO much energy to "Control" without transfer of about 50 times MORE energy than all the brakes turned on in an instant... The ONLY way to implement a system like yours and have it work, is to have some HELP with the Momentum to dissipate ALL the excess energy. Current trains are NOT "mechanically" equipped to handle their mass in a crisis situation.
In Theory Euclid, your system , minus the extra draw bars, or chains, "could" Help the situation at a derail, but its NOT going to work on its own. There is Just way to much Energy, and its in Motion... " A body in motion, tends to STAY in Motion"
I have a suggestion to Euclid. Go build and test it then come back and tell us your sucess and failure. You will have some sucess but you will also have some failure. That is the way life is. Your not paying us on this blog-- remember you get what you pay for.
BARFlyer Euclid, you want to stop the accordion Pile ups on a derailment, no? 1. you will NEED more than brakes , bars and a ECP That is TOO much energy to "Control" without transfer of about 50 times MORE energy than all the brakes turned on in an instant... The ONLY way to implement a system like yours and have it work, is to have some HELP with the Momentum to dissipate ALL the excess energy. Current trains are NOT "mechanically" equipped to handle their mass in a crisis situation. In Theory Euclid, your system , minus the extra draw bars, or chains, "could" Help the situation at a derail, but its NOT going to work on its own. There is Just way to much Energy, and its in Motion... " A body in motion, tends to STAY in Motion"
That is TOO much energy to "Control" without transfer of about 50 times MORE energy than all the brakes turned on in an instant...
The ONLY way to implement a system like yours and have it work, is to have some HELP with the Momentum to dissipate ALL the excess energy. Current trains are NOT "mechanically" equipped to handle their mass in a crisis situation.
I understand that, but I am not trying to fight the kinetic energy or overpower it with brakes, as you suggest. When I say I want to prevent cars from jacknifing, I do not mean doing that by holding back the pushing force from the rear that would force the cars to jacknife. What I mean is preventing the cars from jacknifing by pulling on the cars from the front.
The cars ahead of the derailment pull away from the cars behind it because the cars behind have a heavier brake application than the cars ahead of the derailment.
When I speak of “controlling” energy, I mean controlling the energy of the whole train in a general sense. I do not mean specifically to “control” energy in terms of holding back or resisting the forward push from the cars behind the derailed cars.
Euclid, suppose your train engine derailed? suppose your train engine hit another train car ahead of it, or engine?
I like your theory, and in fact it has plenty of merit and existing proof on many of its concepts,but it will need supplemental Help with MOMENTUM, which IS the biggest challenge here to avoid jack-knife. Dragging a derailed truck along may or may not work depending on what derailed it. On a curve you might end up with the whole train on its side if it kept moving. Experimenting with scale cars and load sensors can be a real eye opener when it comes to the amount of force this problem is fighting.. Its Great to see people thinking and getting it out there
Overmod Euclid In the most fundamental sense, my concept proposal requires that the ECP brakes can communicate with, and control the brakes on each car independently, so braking power can be varied from car to car within the train. As far as I know, this is not a normal requirement with ECP brakes, so they are not equipped with this functional ability. They apply braking to every car in the train as a whole, and if braking force is to be varied, all cars remain synchronized to that variation. So the ECP system does not need to identify individual cars within the train. It treats them all the same. "Basic" ECP will have a control input from load cells in the trucks or bolsters, controlling the brake application relative to the car weight. There is nothing new in modulating ECP proportionally on a car-by-car basis; the novelty is entirely in using the braking to keep sensitive and proportional tension across a putatively derailed car...
"Basic" ECP will have a control input from load cells in the trucks or bolsters, controlling the brake application relative to the car weight.
There is nothing new in modulating ECP proportionally on a car-by-car basis; the novelty is entirely in using the braking to keep sensitive and proportional tension across a putatively derailed car...
I see your point that I am incorrect in saying that ECP normally has no need to be able to distinguish one car from another in a train. It does indeed do that with car weight sensing for the purpose of matching individual car braking force to car weight, as you point out. And the system knows how to make those decisions based on load sensors on the car trucks telling the system what each car weighs.
I would dispense with that feature for the system that I am proposing because the cars will all be identical, and either be loaded or empty. The system could just switch between loaded and empty trains. The buffer cars could have their own built in braking response to match their unique loading.
However, what my system does require is the ability to know the location of each car in the train in order to create varying ranges of braking throughout the train during a derailment.
You mentioned some ways of establishing car location which might be the ideal solution, but I have no exact technical solution to offer. My thought about using the communication cable was just to have the system take a walk down the cable and identify cars as it goes. I have no idea what the cable will be capable of, but one reference calls it an “information super highway” for data. So I figured it could count the cars.
But, in any case, my point in bringing this up was in response to some earlier comments where someone said that it would be necessary to keep the cars permanently coupled so the system would know where they are in the train. And while I have been suggesting the benefits of semi-permanent drawbar coupling, those benefits do not include a need to keep the cars in a certain order. There is no such need because the system will be able to determine that car order within each train.
EuclidYou mentioned some ways of establishing car location which might be the ideal solution, but I have no exact technical solution to offer. My thought about using the communication cable was just to have the system take a walk down the cable and identify cars as it goes. I have no idea what the cable will be capable of, but one reference calls it an “information super highway” for data. So I figured it could count the cars.
Part of the point of the information superhighway is precisely that it doesn't care 'where' the individual devices are along the bus; it only cares WHAT they are. In simplest form, via something like an Ethernet MAC address or a dotted IPv4 or IPv6 address. That way, no matter where your device is, or however it gets packets routed to it, the stuff goes to and from the device correctly... however long it may take, or how many handshakes re-established or packets resent/buffered to get the data through.
But you will immediately notice that these modern protocols say little about the actual order of the devices on the bus. For that, you might need something like a variant of Token Ring, which passed its tokens around the cable run and could generate you an ordered list of the stations it passed through on its way (which would give you an accurate assessment of variable trainlength, the status of any locomotive(s) or special devices through which the cable runs (such as monitors for special conditions that would be applied in the field to a given car, for a purpose like detecting excess pressure or controlling external heating), and some other things.
The catch is that it's media-specific; there's no real good way (that I know of) to do it with wireless modality without a VERY large amount of frequency agility, on top of which you would then have to do your type 1 and type 2 security. And you need both an outbound pair or set of pairs and a return pair going through all the devices. If one device goes bad, or one connector develops noise, or one wire pulls out, the whole shebang instantly reverts to uselessness... and you need something like a TDR to trace where the actual break is, assuming you have some way to command power-on and set passthrough on all the individual devices from the box that the TDR is in. I would not want to have to sell this kind of arrangement to anyone in industry, particularly when it is so much simpler to assign each car its own distinct IP address for PAN, and subaddresses on a known scheme for all the devices on that car, and just have the distributed agents determine the order, the data schemes, etc. and set up the train's data representation on whatever monitor systems -- on the locomotive, in the cloud, in the lineside fabric, wherever you want them -- the system is designed to have.
And lots of helpful parallels, and precedents, in IP protocol for this type of data transmission, even the low-latency parts of the signal. I won't go into that, but go over some of the IETF RFCs if you are interested, to get a sense of the reasoning and philosophy...
I suppose you could wire the cable in such a way that each device physically/electrically encountered along the cable length would set itself with an ID number in a sequence the computer would recognize, and then all subsequent events would be based on that. A model to follow might be the old Salutation protocol, in which devices determined, by 'talking' among themselves and 'knowing' their capabilities, which of them were going to be 'master' of a particular office task. (A fax machine would take control of the telephone system until the fax was received; then a copier-printer would take control of printing the document, etc. -- the point being that no Master Office Computer was needed to decide who was best at controlling a particular job, *and what you got depended on what devices were accessible to the Salutation network at runtime.*
I wouldn't depend on keeping the cars in a physical order to have the system work, even if you think you have reliable people. What happens if a rake of cars is being serviced when the rest of the train goes around a loop or is wyed? If an intermediate segment is taken out for servicing and then returned to the end of an available unit consist? As with computers, probably best to do 'run-time binding' and avoid all the artifactual pitfalls... as long as you do full equivalent of POST just the same as (and probably as the first steps of) your brake test. BITE for ECP is going to include some test of the "P" (proportionality) both for application and release, and this is probably an ideal way to test the drawbar transducers and their calibration without additional time or trouble.
Someone mentioned that some cheap structured-light devices, perhaps even a couple of offset Hall-effect sensors, could give you an accurate enough indication of 'lateral deviation from the railhead' to signal derailment. The logical place for this device is under a truck sideframe... from which a little more directed light into the wheel-rail interface, perhaps also reading the reflective profile of wheel flats and wear profiling, is an easy thing to arrange. (How you keep the devices clean, and calibrated, is up to you.) Note again that all this stuff is managed as part of the 'smart car' internal network, with its own explicit and inherent methods of security, and only the high-level and processed signal information needs to go across the 'train-bus' (whether cable or wireless part) or out to lineside transceivers or distributed communication fabric.
Federal law requires a train list that shows the postion of every car in the train. Just download the train consist to the computer and be done with it.
No poling, no complicated communication protocols, just a flat file.
If you really want to be fancy the computer on the engine "phones home" at regular intervals to get the most recent AEI updated train list.
dehusmanFederal law requires a train list that shows the position of every car in the train. Just download the train consist to the computer and be done with it.
I mentioned that as a programming possibility near the beginning of the thread. And no question that it's better than nothing... as long as it references only the car order, and the cars themselves are 'smart' (whether individually or via cable)
But it is not a slam-dunk perfect alternative if other information about the consist is used, particularly the car weight as given. Three words: Remember Duffy's Curve. In computer terms, GIGO. And it doesn't really matter if it's random GIGO, or unintentional/ignorant GIGO, or highly intentional GIGO...
Meanwhile, in general terms I would not be particularly happy depending on someone crossloading a conductor's carlist as a significant part of a safety-critical application. Not that anyone ever makes mistakes on Federal paperwork, of course! I'm concerned with how that file gets into the safety system -- thumb drive? Automated subroutine in a waybilling program? -- and what other things might be compromised if providing that AEI file is necessary.
Again, you are talking about applying Euclid's concept to loose car railroading, while the first application is of course oil unit trains.
daveklepper Again, you are talking about applying Euclid's concept to loose car railroading, while the first application is of course oil unit trains.
The requirement for an accurate consists is for all trains, loose car or unit. If ULDX 12345 is loaded hazmat and it's the 45th car from the engine then the consist in possession of the crew has to show its the 45th car from the engine, regardless of what the cars on either side are or what they carry, whether its a unit train or a general freight train.
Here's a philosophical question, will the entire unit train be considered one "car". Some railroads consider drawbar connected, multi-platform cars as one "car", some railroads consider each platform to be a separate "car". Will the unit train be one car or many cars?
daveklepperAgain, you are talking about applying Euclid's concept to loose car railroading, while the first application is of course oil unit trains.
Dave Klepper,
The idea of using the train consist list may have suggested that this safety concept was being proposed for loose car railroading in general, meaning all freight trains. But the intent is just to use the proposed concept on oil unit trains, as you point out. However, those unit trains may be any of the following:
1) Trains composed of loose cars from a captive pool.
2) Trains composed of loose cars in a captive consist.
3) Trains composed of semi-permanently coupled cars in a captive consist.
In any case, the cars must be captive because they will have ECP brakes and derailment sensors, and not be set up to operate in consists where standard air brakes are dominate. Ideally, the unit oil trains will also each be composed of identical cars in terms of weight and capacity.
The idea of using the consist list was suggested as a way to tell the ECP automatic derailment response system where each car is located within the train. That way, if a car derails, the system will be able to control the cars behind the derailment differently than the cars ahead of the derailment.
I would look for a way to have the ECP system automatically read the identity of cars in the train for the purpose of learning the order of cars. Each car would carry its own identification code which the ECP system could read.
I think you may have already suggested a far simpler system IF all cars are identacle and fully loaded or completely empty, simply counting cars from front to rear of train, each car registering its number in line.
Why not throw GPS into the mix? While using the car numbers is a good idea, a simple transposition in a car number can throw things off. A human might spot that - a computer probably won't.
I'm sure an algorithm can be written that would factor in the car list, car characteristics, and relative distance from the locomotive to provide a fairly concise list of what's where. In addition, some logging would provide information on what went where with the train does jackknife during a derailment.
It would be a simple task to initiate a query of the train prior to departing, or if there was a change in the consist. It wouldn't need to be an on-going, dynamic process. On receiving the query, each car would respond with its number and lat/lon. A little number crunching and comparison and you'd have the information you needed.
The GPS approach would require the GPS receiver to be near the middle of the car, no matter where the rest of the processor was located.
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...
tree68 Why not throw GPS into the mix? ... I'm sure an algorithm can be written that would factor in the car list, car characteristics, and relative distance from the locomotive to provide a fairly concise list of what's where. In addition, some logging would provide information on what went where with the train does jackknife during a derailment.
Why not throw GPS into the mix? ... I'm sure an algorithm can be written that would factor in the car list, car characteristics, and relative distance from the locomotive to provide a fairly concise list of what's where. In addition, some logging would provide information on what went where with the train does jackknife during a derailment.
The individual vibration-sensing modules all have their own small GPS core, and they all contribute to the NDGPS localization.
A problem is that the distance to GPS modules in cars on adjacent tracks may 'interleave' with the position information for the cars in the train proper, and so some intermediate processing with GIS information would be needed to resolve the situation. Lots more work, and possibility for errors to creep in, than just analyzing nearest neighbors, I think.
There is a much more important use for the GPS and GIS: it becomes possible for the cars to 'know' if they are on or approaching a curve, grade, bridge, etc., and command their braking appropriately. Also true of other approaching trains or standing cuts, too. One thing that would become possible is to go to 'high rate' scanning for defects and anomalies, starting sufficiently prior to a 'meet' that any problems conducive to derailment could be managed...
The more I thought about the issue of using the carlist information to help set brake order, the more I thought the brake-system's car ordering ought to drive the carlist ordering, not the other way around. Compare the two and identify where there are any 'discrepancies' - then walk the train if necessary, or scan it, to resolve.
Dave, how would you implement something that reads IDs from one end to the other with a minimum number of differential conductors?
Point about the 'unit train' -- leaving aside considerations of car type and shipper/leaser utility (which would mandate the special brake apparatus but NOT dedicated consists) the concern of maintenance was raised. I don't think I'd want more than about 10 cars semipermanently coupled at a given time, and certainly not a whole train's worth. If any one of those 'rakes' gets turned relative to the rest of the cars in its train, any hard-coded representation of car IDs is now backward. This should be checked for at every 'runtime' (pun intended) and the car order should be known with high data integrity at every runtime. I argue that it should be built automatically and subject to a minimum of human interaction, whether required, consequential, or malicious.
OvermodPart of the point of the information superhighway is precisely that it doesn't care 'where' the individual devices are along the bus; it only cares WHAT they are.
Lets just skip the wire and do wireless. Have the car inspector "marry" the adjacent cars, or build the consist at the time he connects the air hose. Each car just has to be told who it's neighbor is.
-Don (Random stuff, mostly about trains - what else? http://blerfblog.blogspot.com/)
Our community is FREE to join. To participate you must either login or register for an account.