tree68 Euclid In my opinion, the strengthening of tank cars for a 56% less chance of the random incineration of a large number of people is not a convincing solution to the problem. Accomplishing that over ten years as the oil traffic booms to higher and higher levels makes the solution seem even less convincing. Yet you say yourself that your proposed solution is less than 100% and will, in fact, only work under certain circumstances.
Euclid In my opinion, the strengthening of tank cars for a 56% less chance of the random incineration of a large number of people is not a convincing solution to the problem. Accomplishing that over ten years as the oil traffic booms to higher and higher levels makes the solution seem even less convincing.
Yet you say yourself that your proposed solution is less than 100% and will, in fact, only work under certain circumstances.
My point lies in the word, “convincing,” and the key sentence preceding what you quoted, where I said, “Part of what I am proposing is a solution that appears to match the problem for the purpose of convincing the public and the regulators.”
I am not asking for a perfect solution in order to be convinced that it is enough. All I am saying is that, to my ears, the proposal to make tank cars somewhat safer over ten years seems laughably insufficient as a solution to the public perception of this oil train crisis. And in my opinion, the public and the Senate hearing will have the same reaction.
In this sense, all I am referring to is the feeling of the solution matching the problem in the proposal stage. The problem sounds bold. I think it calls for a bold sounding solution. I don’t see this as a contest for the best solution. For all I know, the stronger tank cars could be more effective than what I am proposing. But I think they need all the solutions they can find and put together in order to match the gravity of the problem.
And a big part of that problem is convincing the politicians, public, and regulators, at this time, that the industry has an adequate solution, rather than expecting them to wait ten years for the results. There is a lot to lose if they are not quickly convinced.
If conditions are not right, most of the time brining the train to a stop as qukcly as possible and as uniformlhy as possible will be the best approach.
A single car not failing during a catastrophic derailment may be enough to prevent the ignition of the product, even if other cars do fail. Might be one heck of a spill, but the chances of it catching fire are just that much less.
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 EuclidI am not sure I understand your point. Since the cars are being placed in service as they are built, there is no additional cost, over and above the increase per unit due to the improvements. Once a car rolls out the door of the factory, it becomes part of the improvement of safety. The return on investment is actually quite high. As you note, a new brake system must be completed in full-train increments. That must necessarily include enough rolling stock so that trainsets can remain complete - a bad ordered car must be replaced by another similarly equipped car, so it's not even 100 car trainsets - you need spares of both cars and suitably equipped locomotives.
EuclidI am not sure I understand your point.
As you note, a new brake system must be completed in full-train increments. That must necessarily include enough rolling stock so that trainsets can remain complete - a bad ordered car must be replaced by another similarly equipped car, so it's not even 100 car trainsets - you need spares of both cars and suitably equipped locomotives.
I don’t see much hardship in the need to add the improved brake in full train increments when the overall objective is to convert the entire fleet. Even the strengthened cars will probably go into service in blocks of multiple cars. Suppose the entire production of either strengthened cars or cars made with the new brake was 200 cars per day. How much real benefit would be realized by the ability to put the strengthened cars into service one at a time during that day, versus having to wait half a day for each 100 car train with the new brakes?
You say that the return on investment on strengthening one car is quite high. I don’t know how high it would be, but one strengthened car in a 100-car train will not have much return on investment considering that there will be 99 other cars available to rupture and start a fire if the train happens to derail.
Cost certainly enters into the solution in many different ways. I do not expect that what I am proposing will be cheaper per car than strengthening them. Probably if they adopted what I am proposing, they would also strengthen the cars. With all that is at stake, they need a solution that is as near to 100% effective as possible. And considering the risk of losing the oil business, the cost of the near perfect solution could be justifiably very high. Slowing down the oil trains has a cost, and so does rerouting them. Oil train derailments pose the risk of extremely high cost. So does the effect of oil train disasters on the regulators. So I have no idea how much cost is too much for any given safety measure.
Part of what I am proposing is a solution that appears to match the problem for the purpose of convincing the public and the regulators. In my opinion, the strengthening of tank cars for a 56% less chance of the random incineration of a large number of people is not a convincing solution to the problem. Accomplishing that over ten years as the oil traffic booms to higher and higher levels makes the solution seem even less convincing.
Introduction of one "new" car to a train increases the overall safety of that train by some percentage. Once all the cars in a train meet the new standard, the safety factor is increased to that ~56% figure cited earlier.
Since the cars are being placed in service as they are built, there is no additional cost, over and above the increase per unit due to the improvements. Once a car rolls out the door of the factory, it becomes part of the improvement of safety. The return on investment is actually quite high.
Now for statistics - a train made up of all new cars is supposed to be ~50% safer than one made up of old cars. If we assume that the proposed brake system increases safety by ~50% we now see a 75% increase in safety. And that last 25% was far more expensive to achieve than the first 50%.
tree68The addition of some form of enhanced braking system, whatever it may be, will require not only that the system be installed in cars currently being built, but all cars currently in service must be retrofit as well, not to mention associated hardware, software, and communications.
I am not sure I understand your point. The overall objective would be to have all tank cars meet the new strength standards, but it would not require them all to meet the standards before any safety increase is realized. Each car made or converted to the new standards will increase safety.
The same could be said for this new brake concept except that the safety increases would have to be in something like 100-car increments. This is because the individual cars in a train must all be converted to the new braking system before they can operate that system. So each new 100-car train will increase safety.
If the entire tank car fleet must remain as loose cars (not captive or dedicated to specific trains in any way), then it would require the entire fleet to be converted to the new brake system before it could begin operation. Or, at least, it would require all the cars in any random train to end up with all loose cars that happen by chance to be equipped with the new brake system.
But I assume that the entire fleet is not loose cars right now, and does not have to be all loose cars. If a conversion were made to this new brake system, I expect the converted cars will immediately be grouped together so they can run as trains as early as possible and utilize their new brake system.
So both the car strengthening and this new brake system would be an incremental process gaining advantage with each increment.
At 25 miles mph, there is little danger of pileups? Then, the solution is to lay a third track for oil movements, so the oil trains will not get in the way of the trains moving faster.
Johnny
EuclidThis the first time I have seen a quantification of the safety improvement from tank car strengthening. It would be interesting to learn whether my idea would prevent more than 56.6% of the potential catastrophes. Also interesting would be the result of combining my idea with the strengthening of tank cars, and the amount of time needed for each of the two approaches.
A third question is the relative cost of the two approaches, and hence the return on investment.
The replacement of tank cars with cars built to the new standards is already underway, and will be complete when manufacturing facilities are able to complete the required number of cars. At any rate, the cars will be generally be replaced at or about the time they "life cycle" out.
The addition of some form of enhanced braking system, whatever it may be, will require not only that the system be installed in cars currently being built, but all cars currently in service must be retrofit as well, not to mention associated hardware, software, and communications.
The author does indeed dismiss the 25 mph speed limit, and I do understand why the speed reduction is a non-starter in the industry. And in so dismissing the 25 mph speed limit, the author dismisses the goal of preventing tank cars from piling into a very small space because he only connects that outcome with a 25 mph speed restriction.
However, I take him to mean that achieving that goal of preventing cars from piling into a small space would be far preferable to strengthening tank cars. He says that preventing the piling of cars into a very small space would prevent 100% of the potential catastrophes whereas strengthening tank cars will only prevent 56.6% of potential catastrophes. So he cites the best solution, but says that it is unattainable because the industry will not accept the speed reduction.
I would say my solution is attainable, but it will not prevent 100% of potential catastrophes. This is because it will not prevent tank cars from piling into a very small space in the event head end collisions with other trains; or head end derailments due to other causes; or rear end collisions with following trains. And it will not work in some mid-train derailments, depending on extenuating circumstances.
This the first time I have seen a quantification of the safety improvement from tank car strengthening. It would be interesting to learn whether my idea would prevent more than 56.6% of the potential catastrophes. Also interesting would be the result of combining my idea with the strengthening of tank cars, and the amount of time needed for each of the two approaches.
Euclid Here is a quote from Progressive Railroading (February 2014) from an article by Toby Kolstad titled, There's a lot at stake in the tank-car design discussions: “There is one common denominator to all the tank-car derailment tragedies of late that has hardly been mentioned: Train speeds all exceeded 40 mph. High-speed derailments almost always involve dozens of cars piled into a very small space; in derailments at slower speeds, cars tend to stay coupled together and upright. Limiting the speed of trains with blocks of haz-mat tank cars to 25 mph would reduce the catastrophic consequences of derailments involving these cars by almost 100 percent. That would be far more effective than the 56.6 percent reduction estimated by the AAR's own research for the tank-car changes they have suggested,…” [My emphasis added]
Here is a quote from Progressive Railroading (February 2014) from an article by Toby Kolstad titled, There's a lot at stake in the tank-car design discussions:
“There is one common denominator to all the tank-car derailment tragedies of late that has hardly been mentioned:
Train speeds all exceeded 40 mph. High-speed derailments almost always involve dozens of cars piled into a very small space; in derailments at slower speeds, cars tend to stay coupled together and upright.
Limiting the speed of trains with blocks of haz-mat tank cars to 25 mph would reduce the catastrophic consequences of derailments involving these cars by almost 100 percent. That would be far more effective than the 56.6 percent reduction estimated by the AAR's own research for the tank-car changes they have suggested,…”
[My emphasis added]
For the record, here is the full article from Progressive Railroading
It seems to me as if he's primarily discussing the need for increased structure (and its cost and weight) rather than ever seriously considering that a reduction in speed is an answer.
... the article focuses on the problem of tank cars piling into a very small space, and the preferable alterative outcome of having the cars stay coupled together and upright ... preventing the cars from piling into a small space will eliminate the catastrophic consequences of oil train derailments by almost 100% ... this improvement would be far better than what will be achieved by the AAR proposed tank car changes to make the cars more crashworthy.
The article, I think, does not 'focus' on these things so much as mention them as rhetorical devices. He appears to me to be commenting on the RSI proposal... with the point of his reductio argument being this:
" ... However, a 25 mph speed limit is as impractical to railroads as insulating and jacketing all existing tank cars in haz-mat service is for rail-car lessors." (emphasis mine)
The author goes on to say that reducing the speed limit is not an acceptable solution, although he does not say why that is so.
If a focus in modern railroading is to accomplish 'one-speed' operation at a cost-effective speed that maximizes 'throughput' ... anything that disrupts that speed by moving more slowly is just as damaging as something moving more quickly (e.g. Amtrak) -- now with the added pain that a slow-moving disruption takes longer to clear a given stretch of track. Do I need to go into the increased cost involved in eight-hour mandatory recrewing when the train goes a maximum of 200 miles per crew, with all the latencies and uncertainty going with change locations, added van time, etc.?
I think the article DOES say that the solution involving mandatory armoring and jacketing is perceived as relatively unattractive, and it certainly does point out an important cause of the problem in a way that 'plays into the hands' of someone advocating a differential-braking solution. I'd be tempted to write a letter to Progressive Railroading that succinctly makes the point that there ARE at least in theory ways to reduce potential damage in 40-mph-plus accidents down to levels of 25-mph-and-below, and we should investigate them as 'solutions' to the present quandary regarding 'safer' tank-car oil transport.
He seems to say that reducing speed to 25 mph is not acceptable, but to 35 or 40 maybe.
It is interesting that the article focuses on the problem of tank cars piling into a very small space, and the preferable alterative outcome of having the cars stay coupled together and upright. This is precisely the objective of this safe oil train idea that I am proposing; that is, to avoid the outcome of piling cars into a very small space; and achieving that by pulling on them while they stay coupled together.
The article says that preventing the cars from piling into a small space will eliminate the catastrophic consequences of oil train derailments by almost 100%. I assume the author means rupture and fire when he refers to catastrophic consequences.
The article says this improvement would be far better than what will be achieved by the AAR proposed tank car changes to make the cars more crashworthy. So the author is on the very same page as I am, but he arrives at that page by reducing train speed, whereas I arrive at that page by the method detailed in this thread. The author goes on to say that reducing the speed limit is not an acceptable solution, although he does not say why that is so. Overall, I believe that the article has identified the problem, but not the solution.
BARFlyerEuclid, 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
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
BARFlyer,
This concept will only apply to mid-train derailments. It cannot help with head end collisions with other trains or motor vehicles, or any type of event that causes the head end to derail. It also cannot help with rear end collisions.
With mid-train derailments, the system will help mitigate the derailment damage to varying degrees. And there will also be mid-train derailments that are not helped at all by the concept. Location of the train will play a big role in the success or failure of the system. A successful outcome could be prevented by bridges and trestles being snagged by the derailing cars, for instance.
So it is not a panacea. But I think the damage it would prevent would make it worthwhile, especially if that damage ruptures tanks cars and burns people to death. This system would be completely unnecessary if tank cars were made invincible to the destructive forces produced in a high speed derailment. But I don’t believe that is practical.
The value of hauling the crude oil is limited by the market value of the refined products. So, I don’t think the value of hauling crude oil is high enough to justify the cost of encapsulating its volume in a rupture-proof container during shipping. On the contrary, for instance, the value of hauling nuclear waste is high enough to justify the cost of encapsulating its volume in a rupture-proof container.
So, if you can’t put the oil in a rupture-proof container, you can work on reducing the forces that would rupture the container.
CSSHEGEWISCH Why do I get the feeling that this whole system is getting overly complex and still doesn't address the issue of where all the kinetic energy will go
Why do I get the feeling that this whole system is getting overly complex and still doesn't address the issue of where all the kinetic energy will go
The most of the kinetic energy is dissipated through braking as it normally is in stopping a train. Some of the kinetic energy is dissipated through the resistance of cars running while derailed.
That's exactly what I mean.
The 'wireless' connection has antenna strength determination at each end. All the cars 'handshake' regularly to see what they're adjacent to -- this lets any computer that can reference the network understand how the cars are ordered. IF cars are switched or changed, the result is immediate. If the train separates for any reason, the system will know it (and accommodate). If you want to buffer the history, you can probably store the entire history of what either end of a car has been connected to.
There needs to be backup redundancy that does not share a common mode (e.g., no OFDM for noise reduction masquerading as independent multiple channels) and this is one place a wired (or wired with wireless terminal links) system may be attractive.
The capacitive-coupling system IBM developed years ago (for exchanging people's business-card information when they shook hands, of all things!) would work nicely for this general level of data exchange, over a 'making up the air hose' connection...
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/)
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.
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.
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.
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.
daveklepper Again, you are talking about applying Euclid's concept to loose car railroading, while the first application is of course oil unit trains.
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?
Dave H. Painted side goes up. My website : wnbranch.com
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.
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.
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.
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...
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.
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...
Overmod,
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.
Euclid, suppose your train engine derailed? suppose your train engine hit another train car ahead of it, or engine?
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"
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"
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.
Our community is FREE to join. To participate you must either login or register for an account.