Well here is a cautionary, non-software, tale about rail. My brother is a mechanical engineer and he did a sandwich course, and the year he spend in industry as part of it was at British Rail Engineering in Derby.
He told me that the Potters Bar rail crash was inevitable once the railways were split up into parts. Here is why.
Hard metal on hard metal is not a good combination; it eventually results in stress and fracturing. Thus the safe combination is hard metal and soft metal. As it is easier to replace train wheels than rails, the rails are made of hard metal and the train and carriage wheels of soft metal. This was fine, well known, and controlled when one company controlled everything.
Then we had privatisation. Rolling stock was in a different company to the track. Staff came and went and the knowledge quickly disappeared. After a few years, the rolling stock company noticed that they were continually replacing wheels and looked for a solution. Naturally the solution was to use harder wheels.
And this gave us the critical condition of hard wheels and hard track; train wheels are actually slightly tapered on the flanges in order to steer themselves round corners, but can also set up slight oscillating motions on bends, resulting in the flanges repeatedly making contact with the rails and effectively giving them a hammer blow.
The moral of the story is that when you break up a system (track and rolling stock) into constituent parts and separate companies, each will optimise its own subsystem, both in engineering and cost/profit terms and no-one looks after the bigger systems picture.
I bet the government that privatised the railways did not do a risk analysis on the loss of implicit systems knowledge that splitting a system up would cause.
Thanks for this. Very worrying, given I drove my family around Florida recently in a Prius!
It's interesting how simple basics can get drowned out. I suppose it happened to NASA with Challenger.
One of the things that attracts me to rail, over road, (forthcoming book The Cost of the Car) is the engineering heritage. Safety engineering began with rail, and signalling makes a nice student exercise in sequential system design, and, more recently, in formal analysis.
I worry whether the same art is being applied to car design. Of course, it is entirely absent in road design, which is inherently lethal anyway, as the annual carnage shows.
And, of course, it is absent in the training of most 'software engineers', as is engineering per se.
I too began with µprocessor programming in assembly language, and believe as much has been lost as gained in the use of 'standard' HLLs. I have had unending difficulty adapting to universal hacking – the lack of any real specification, design, or analysis, with software.
I'm trying to assemble a series of texts called Electronics, Systems, and Programming (http://www.openchannelpublishing.com/esp.html) that combine a more formal approach to software, and would welcome a proposal, particularly wrt embedded concurrent/reactive systems. (You get £2.50 back a book, instead of 80p at most, and a lower selling price, hence more sales. And yes, that is realistic, especially with e-books on the rise.)
The CPA community is still badly in need of books that reflect its idea and ideals. The right people are always too busy, I guess.
On 31 Mar 2010, at 03:04, Tony Gore wrote:
from an engineer who used to work at Ford in around the same era that I was working in automotive. The key phrase he uses is
Although not common over here in the UK because of our penchant for stick shift (manual gearboxes), most cars in the US have automatic gearboxes and cruise control. One of the standard signals to cruise control is the brake signal to disengage it.