He’s not referring to sparks during operation – he’s referring to accident situations where the equipment is bashed or wires torn out while the brake system is energized.
In part this is a reason for the extreme low voltage: less dielectric strength is required to keep a short from developing. However, at the current density involved to make the trick work, any arc struck will probably act like a good welder’s arc, and produce similar heating of ‘whatever’ completes the circuit, probably some piece of bent or torn metal that is a ‘good enough’ conductor for a few coulombs’ worth of anxious electrons…
I suspect one way to address this is to have very quick-acting interrupters at the capacitors, which will act first to interrupt current and second to physically separate the cap array’s terminals from any exposed circuitry. It should be possible to ‘armor’ the cap enclosures so they ‘resist like a solid block’, to paraphrase Jules Verne, and do not suffer sufficient damage to expose the delicate nanostructure and the subatomic particles therein… If the processor stops receiving a ‘full integrity’ signal for any reason, the fast-acting device triggers; even if there have been the beginnings of a shorted discharge, it will go out and not re-establish on that particular car. (Is that enough safeguard to overcome most of the objection for practical, operational purposes? If not, what more should be done or assured?)
I would think that in the event of an accident that would damage electrical components or their enclosures such as to cause electrical sparks, those sparks would be lost in the sparks that result from metal parts of the train impinging on other metal parts, rail, tie plates, spikes, and rock.
But what about the jury when that particular accident’s case goes to trial, who will certainly be told otherwise about where the fatal sparks may have originated … ?
If there is flammable vapor outside of the tank cars of oil, any spark will ignite it, no matter whether it is intense sparks like an arc welder or finer sparks such as the ones that can come off of the brake shoes of conventional air brake systems.
Exactly., Euclid Just as there have been zero records of any false break-in-two executing an unwanted emergency air-brake applcation, so I expect there will not be a false derailment executing an unwanted brake application of any type, yours, mine, or anyone’s. The equipment must be proved reliable in that respect before in it approved even for testing service. Much is made of the experience with “kickers,” cars that apparently go into emergency on their own. I surmise this results from less than optimum maintenance of the existing air-brake sysems. Does anyone have any experience with “kickers” on unit trains?
I am not answering ypu, B., because you won’t listen to facts. But rhere are others that will…
The kiind of problem you are discussing is well known in electrical and electronic engineering and there are a number of safegaurds against that problem and tests to insure it cannot occur. And except for BARTD and Metro Washington, whose designs had serious objections from my good friends in the industry (the reliability of the computer controlled PATCO Phila-Lindelwald Line isone of th the responsbility of them), there have been no “transient electrical current caused operational gliches,” only those caused by improper operation, as in a CTA incident about a year ago.
The run-away caboose in the latest issue of CLASSIC TRAINS cannot mean that the regular braking system isn’t a reliable one.
Magnetic track brakes have been in use for over 100 years. Electric control of braking for 110. Wheel slip technology for about 20. Where and when were the transient current incidents?
The facts are that on my territory, there are 4 Signal Control Points, that periodically and for as yet undetermined reasons take a ‘hit’ wherein the control point drops signals that have been lined and roll those drops back to adjoining control points, place all switches associated with the control point in a ‘out of correspondence’ indication and place everything ‘in time’.
Company signal personnel and as well as the manufacturers highest level of technicians have yet to find the answers and formulate effective solutions.
The more electronic equipment becomes, the more subject it becomes minute currents that for whatever reason get established in the equipments operating proximity. You have electronic circuits being operated at millivolts and less and other electrical gear in the general operating area being operated with multi-kilovolts, with all the radio frequency and electromagnetic noise that they generate. Notice that virtually any piece of electronic equipment that gets purchased has some form of disclaimer about electrical and radio frequency interference. We know a great deal about electrical operations and various kinds of interference, there is still a great deal we have yet to learn. Anytime you think you know it all, you will be surprised when you find out something new.
The more computer controlled locomotives and their associated control circuits become, the more frequent ‘unexplained’ failures are happening. At it’s most innocuous level, the train is stopped and the locomotive is ‘rebooted’ - ie. shut completely down and the full restart procedure is followed to get the locomotive operating properly again. The next level is that the reboot does not solve the issue and the locomotive is not usable and must be routed to a shop - a shop that may or may not fix t
Without intending a criticism either of the poster or his railroad: this problem in no way invalidates what Dave was saying about control modalities. What technology is involved in the signal system – physical relays and voltage relative to track potential, perhaps? I’d be looking at transient changes in trackbed potential – not that you could predict 'em or even read 'em cost-effectively in realtime.
Full differential signaling (assuming you could establish a high-integrity means of physical detection, which I wouldn’t consider difficult) should get rid of any tendency for ‘stray’ signals, or superposed voltages even in synchronous phase, to cause modal output to drop in that fashion. Note that I say ‘should’. I will let Dave take up the various issues with how differential systems can be made to fail in the field, as he knows much more on the subject.
I am srill asking you for specific instances of what you are talking about. Control of distributed power goes on and on, and I know of no such instance as you state. The equipment is designed to do the job. It is not your consumer-grade ctmmunications and compupting stuff. Similarly, magnetic track-brakes. MU control of rapid transit and commuter and light rail equipment. With the three exceptions I hav mentioned, Washington Metro, BARD, and a serious employee error at CTA, the material has proven glitch-free.
Anything new applied to freight railroading undergoes very regorous testing.
A posting on Slashdot yesterday was about a report on the “2005 Camry L4 Software Analysis” done by Michael Barr of the Barr Group in regards to unintended acceleration. He demonstrated that it was possible for the engine control computer to get into a configuration as to where it would ignore changes in accelerator pedal position and brake application. This was due to the software violating multiple MISRA-C rules on software design for safety critical software in automobiles along with a couple of hardware design short cuts.
One of the problems noted with the engine control software in question was that because of the nature of the software problems, software induced errors were not recorded.
Electromagnetic braking would require software control, the trick is keeping the software involved as simple as possible.
Electromagnetic transients are an issue, but those should b
ECB is essential if magnetic track brakes are to be used.
My concept is for emergency use only, only with full tread brake application with the track brakes full on added.
My concept does not involve increasing magnetic track brake strength above what is used on typical modern light rail cars, even though a loaded oil tank car is heavier.
I didn’t get in the railroad game yesterday and by your own admission you haven’t been in the real world railroad game for many years.
My carrier doesn’t use DPU’s in the territories I have worked and continue to work, therefore I don’t have any day in day out experience with the problems that DPU generate in the real world - all I can offer is that like anything else in my 49 years of hands on railroading - nothing is fool proof or trouble free.
Just because the electronics are industrial grade doesn’t mean they are without their own set of problems.
I am not saying your idea can’t work - it is not going to be as simple and trouble free as you are postulating. With any system there are multiple areas for failure and the railroad enviornment is the Hall of Fame for the application of Murphy’s Law - ‘If it can fail - it will. If it can’t fail - it will still fail.’
Or, as I argued, keeping some artificial intelligence/expert-system oversight of the software in the design.
Sometimes, KISS becomes… just stupid. At those times a little redundant complexity can resolve matters far more effectively than even expedient algorithms.
Note the emphasis in /. on errors in design, and then errors in design regarding detection of the errors. That was the problem; I think the emphasis should be placed on how to overcome issues like this in the design and possibly genetic evolution of algorithms used in critical software. I’m reasonably sure a good testing protocol would have caught most, if not all, of the issues Barr identified. (On the other hand, perhaps 20/20 hindsight is not a good predictor for complex projects still in development! ;-} )
Of course rigorous testing and evaluation and experience is necessary to make any new system work. I was not underestimating the time and effort required. It is a new system, even if it uses components used previously and any new system needs testing and refinement before general application. Some known reliable comoponents placed into a system still require testing and debugging.
How much troiuble have you had with end-of-train devices? Particularly those that provide emergency braking from both ends of the train? I would hope my system gets at least as much testing and debuggin as these devises had before general use. I would even hope several deliberate derailments would be included in the testing process.
The point in maintaining simplicity in software (or perhaps more correctly avoiding unnecessary complexity) is to ease the process of verifying correct functioning and ease of tracking down errors. In the case of the Toyota code, the complexity made it difficult for the developers to truly understand the amount of resources being used, specifically how close the stack was to overflow in normal operation. The complexity also lead to the possibility that changing the code in one task would have affects on other tasks. One part of the “cure” is proper partitioning of the tasks in the software.
Reminds me of a story about the first launch of the Columbia. The first attempt at launch was aborted due to a timing issue with the flight control computers, which was promptly fixed and the launch took place three days later (IIRC). The story from a hydraulics guy at Rockwell was “It was a good thing the delay was due to a hardware problem, if it was software the flight would have been delayed six months.”
Perhaps the closest analogy in the RR world would be freight brake valve going into full release when the train line pressure exceeds the service reservoir pressure.
While driving over the road tankers the pucker factor went up 1000% when driving a partially full load. Would the same affect tank trains as well ?
Further reflection might make one wonder if the MM&A derailment could have been initiated by a partially full tank car on the curve since the locos made it thru the curve ? Anyone know if any of the front cars made it thru the curve ?
Electromagnetic brakes might have prevented curve over speed tipping
As Dave points out, his system would have prevented the Lac Megantic accident (albeit by being triggered separately from differential wheel rotation after a derailment had begun!)
With the cut rolling, the alternator would charge up the supercaps or whatever, to the point where the system could be commanded to complete a brake application (and probably, hold the train for some interval, perhaps only a brief one).
Also, as I noted, if the system might in ‘safety’ mode actuate ‘continuously’ from alternator current; the speed will tend to be self-limited to wherever alternator current balances coil current in each associated brake – and the developed magnetic braking balances the longitudinal component of gravitational acceleration…
So even if by a series of fits and starts, the train speed would arguably never have reached the speed that caused the dramatic derailment and pile-up.
We can argue whether the system would have helped or hurt if the first actuation of the magnetic brake in a Lac Megantic type accident scenario came only after the first cars had left the track. I suspect it wouldn’t save that many people, as by the time the brake had actuated and produced meaningful deceleration in the parts of the consist still on the rails, there would already have been enough wrecked and spilled to cause much of the horror that was observed. But this is only an indication that derailment monitoring only is not the best control modality for a distributed electromagnetic brake system…
I’m sure it does, but I can’t imagine carloads of Bakken crude only partially filled, particularly since