This case involves a conflict between different kinds of engineering. Mechanical Engineering and Electrical Engineering differ importantly from Civil Engineering in the nature of their professionalism. The most fundamental difference is that Mechanical and Electrical Engineers tend to produce mass-produced objects. Even high-end devices like airliners come in models. Mechanical and Electrical Engineers try to produce incipiently universal devices, the perfect example being the computer, which lend themselves to being produced for a wide variety of customers, with widely different requirements. Public safety is mostly ensured by testing sample items, often to destruction. Civil engineers tend to produce particular structures for particular requirements in particular locations, and the nature of civil engineering professionalism follows from that. They cannot demonstrate the safety of their buildings by blowing them up, so they are forced into asserting the purity of the design process. At the other extreme, we have Open-Source Software, which isn’t pure at all, but is very self-correcting.

One of the first things the American Society of Mechanical Engineers did, upon its foundation in 1879-80, was to develop standards for testing steam boilers, setting rules under which the boilers were to be pumped up to higher than their certified pressure in a test pit to see whether they exploded or not. About the same time, a leading mechanical engineer was asked whether he favored the licensing of stationary engineers (boiler and engine operators). The leading mechanical engineer replied that he did not, because the principle requirement for a stationary engineer was sobriety, and no examination could indicate whether a man was likely to get drunk on duty or not. In our own time, the automobile industry routinely drives new automobiles into brick walls to find out how well the air bags work. A typical automobile production run is a couple of million units, over several years, and it is no big deal to allocate a hundred or so to destructive testing.

I should like to develop two parallel cases of accidents in which hundreds of people were killed, circa 1975-80, for reasons amounting to corporate recklessness and frantic profit-seeking. One involved an airplane. The other involved a bridge.

The first case is the crash of a Turkish Airlines DC-10 at Paris in 1974, with 346 people killed, after a cargo door had popped out in flight, collapsing the cabin floor, and destroying critical control linkages. What eventually emerged from legal discovery was that a there had been a design “bug”; and that this bug had been identified, first in a ground pressurization test in 1970, then in the “Windsor accident,” a non-fatal “Miracle on the Hudson”-type accident in 1972. American Airlines Captain Bryce McCormick, who was very much the same kind of man as Captain Sullenberger, was able to get a damaged airplane back on the ground. Not having access to the rudder, he used the wing engines for “thrust-vectoring.” Afterwards, a corrective modification for the cargo door was worked out; and the Federal Aviation Administration wanted to issue it as an Airworthiness Directive, that is, a recall notice. However, McDonnell-Douglas management pulled strings in the Nixon White House to prevent this, promising to effect the repair privately and without publicity. The airplane subsequently sold to Turkish Airlines (“ship 29”) had not been so repaired; and unidentified McDonnell-Douglas executives (presumably Licensed Professional Engineers) had falsified the airplane’s paperwork to create the appearance that it had been repaired. To do this, they committed the crime of forging the signatures (or rather, seals) of three inspectors. Other airlines than Turkish Airlines apparently got the benefit of informal warnings. A McDonnell-Douglas employee might sit down at the bar next to a United Airlines employee, and whisper something like: “I’d be fired if it got out that I had told you, but there’s a critical problem with the DC-10 cargo door…” Turks being untrusted foreigners, who might very well talk to the New York Daily News if they thought they had been sold a “lemon,” that kind of back-channel information did not penetrate to them. We are not talking about something which really falls within the scope of engineering ethics– political corruption and forgery are still crimes, even when done by a banker or stockbroker. The system of quality control and factors of safety was thick enough that, in practice, it was breached by what amounted to an act of intentional sabotage.

The other case was the Kansas City Hyatt Regency disaster in 1981. A steel-reinforced concrete bridge crossing a hotel atrium (used as a ballroom) collapsed. More than a hundred people were killed, and more than two hundred injured. It emerged that the original designer (A Licensed Professional Engineer) had ignored the required factors of safety; that the steel fabricator had modified the design, making it still weaker, without any recalculation of its strength; and finally, that the welding had been defective. Three acts of “subtle sabotage” were enough to cause the bridge to collapse with a crowd of people under it. Yet no one seems to have done anything amounting to forgery, perjury, or bribing a building inspector. Unlike an aircraft company, the construction firm did not have the apparatus in place to triple-check everything. Granted, there was breach of professionalism, for which the designers were ultimately stripped of their licenses, but there really wasn’t the kind of intervention which would have been obviously criminal, even if carried out by a stockbroker. I was in engineering school, at Cincinnati, at about that time, and when I took Strengths of Materials (taught by a member of the Civil Engineering department), this case was presented. The professor presented it factually, without any great discussion of the corporate climate in which people shave away at factors of safety, in a blithe assumption that no one else is doing the same thing further down the line.

https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse
https://en.wikipedia.org/wiki/American_Airlines_Flight_96
https://en.wikipedia.org/wiki/Turkish_Airlines_Flight_981

Also: Paul Eddy, Elaine Potter, and Bruce Page, _Destination Disaster: From the Tri-Motor to the DC-10: The Risk of Flying_, 1976; Moira Johnston, _The Last Nine Minutes: The Story of Flight 981_, 1976

Electrical engineering is a bit different again, in the sense that very few electrical engineers do applied physics. Most of Electrical Engineering has a kind of identity crisis. There are a handful of traditional Radio Engineers, concerned with signal propagation, but there are very few applications where truly custom-designed hardware makes sense. The vast majority of electrical engineers either produce traditional software, or else they write Verilog, for use with FPGA’s. Verilog is sometimes made up into ASIC’s, but that is economical only for the most mass-produced applications, the crossover point being a million parts or more.

Some years ago, I had occasion to look at a group of “hardware capstone projects” posted on the website of Columbia University’s Department of Electrical Engineering. What impressed me was that essentially none of those projects made sense as electronic products. The assignment was in effect to design and build a circuit board that did something, to show proficiency with OrCad and a soldering iron, etc., but these were all projects, such as a calculator or an alarm clock, which could equally well have been implemented with an inexpensive micro-controller, and a bit of software. Or, in some cases, they would have done equally well as programs to run on a personal computer or a tablet computer, under an operating system. None of the students were doing anything at the supposed core of Electrical Engineering, eg. wave propagation. No one had built a better microwave oven, or anything like that. Of course, I suppose that most of the students got programming jobs, probably in the financial services industries.

One solution to the intellectual problem has been to pad out Electrical Engineering curriculum with Computer Science courses, and even to capture the Computer Science department and refuse to teach Computer Science to anyone who does not enroll in Electrical Engineering. However, much the same basic problem applies to Computer Science. Ideally, someone getting a bachelor’s degree in Computer Science ought to be made to write a small compiler and a small operating system, by way of proving his competence in computational linguistics and resource allocation. Again, however, in market terms, writing a serious compiler and operating system, with all the usual and expected features, is only justified under certain very special conditions. Google itself only _modified_ Linux to make Android. I’m not even really sure whether the sophomore-level Data Structures and Algorithms course can be strictly justified for people who will spend their careers writing SQL code.

Back in 1982, when I took Human Factors Engineering, one of my classmates produced an extra-credit project which I found admirable. He designed and built a screwdriver and a claw hammer, both of which looked very strange, but which were rationally designed to protect carpenters from carpal tunnel syndrome. One admirable recent electronics project I have seen is this, a glove-mounted sonar set for blind people:

http://grathio.com/2011/08/meet-the-tacit-project-its-sonar-for-the-blind/

Note that it is Arduino-based, and that the electronic construction amounts to plugging a couple of off-the-shelf sonar transducers into one end of an Arduino, and a couple of off-the-shelf servomotors into the other end, and connecting up a battery. The activating code is not all that difficult either. The developer’s hardest problems were things like figuring out how to sew sheet rubber, in order to be able to strap the whole business to the user’s wrist. This project was published before 3-D printers hit the market. With a 3-D printer, of course, the developer could have worked up a machine-produced plastic chassis to hold everything, with lugs to attach velcro straps to. To the extent that this kind of thing is taught in a university, it is taught in the Industrial Design department of an art-and-architecture school. The Columbia Electrical Engineering seniors were not doing this kind of work, and that is ultimately a fairly serious critique.

There is one area of electrical engineering which conforms to the expectations of Civil Engineering. This is Electric Power Engineering. At the moment, Electric Power Engineering is a scarcity field, because so many cities have decided that they want electric street cars, and this has swamped the normal demand resulting from electric-grid construction. Overhead wires are traditional civil engineering works which happen to conduct electricity at high voltages.

The historic safety agency for electrical equipment is Underwriter’s Laboratory (UL). As the name suggests, it was originally organized by fire insurance companies. Its business is to test mass-produced electric equipment, and make sure that it does not start fires or give electric shocks. UL is not based on the idea of professionalism. It is based on the idea that insurance companies naturally resent having to pay claims for fires caused by defective electrical equipment, and naturally look out for their own interests, and everyone else’s at the same time. As applied to computers and electronics, UL’s operations are focused on a handful of components (power supplies, wall warts, lithium batteries, etc.) which have enough energy to be potentially dangerous. UL does not concern itself with the correctness of the information generated by a personal computer.

https://en.wikipedia.org/wiki/UL_(safety_organization)

What most electrical engineers are actually doing is computer programming, or to label it as a discipline, Computer Science. I think one can make a case that software is a kind of extreme case of mass-production, in the sense that it is normal to get a disk with a complete set of upgrades and fixes at regular intervals. The dominant issue of Computer Science is complexity. The most trustworthy software is not that produced under a system of engineering professionalism, rather, it is that produced under the system of Open Source, in which any snot-nosed kid is entitled to point out defects. In a sense, Open Source is a logical evolution of quality control practices. The logic of engineering professionalism with respect to Open Source is to be a plagiarist. A kid tells you about a bug in your software, and you fix it, but you don’t give him any credit because he has no engineering license, and the engineering society forbids you to admit that anyone “unqualified” worked on your software. Alternatively, you can deny the existence of the bug, because its discoverer is un-credentialed.

The usual aerospace electronics practice for securing reliability is to do the calculation a number of different times, and see if you get the same answer, and in case of discrepancy, to go with the majority vote. This is of course a carry-over of the traditional nautical fashion of doing navigational calculation. Take an electric switch. It can fail open, so that it does not transmit current. It can fail closed, so that it always transmits current. It can even fail by rapidly flapping back and forth, so that it is neither safely open nor safely closed. One can construct a grid of switches, such that no one switch failure can cause the grid to fail. Some years ago, I think about 1990, I remember reading in BYTE about a British Ministry of Defense initiative for extremely reliable computing, called VIPER. They went the whole length: solve the problem with different algorithms; code the different solutions in different languages; compile them with different compilers; to different processor architectures; and actually build the different processors in different chip chemistries. There were a few other details, such as banning interrupts in favor of I/O polling. There was the maximum possible effort to ensure that there was no common failure point, and that the inevitable errors would not duplicate each other.

Of course, this has to be extended all the way out to the sensors, as was illustrated by the case of Air France 447, which crashed into the South Atlantic in 2009. The airplane had massively redundant computers, and it had three airspeed sensors– but– the three airspeed sensors all worked on one and the same physical principle– the pitot tube, and they all had a common failure mode. This failure mode is not clear, but it was probably icing, maybe with a bit of dust from a dust storm mixed in with the ice. The pilots more or less flew the airliner into the water in good condition (*) because they could not figure what was going on. The accident would not have happened if there had been an additional instrument operating on an independent principle. One proposal is to squirt out a little water, and track it with a Doppler radar as the air-stream carries it away.

(*) The angle of attack was pretty high, but informed opinion seems to be that the crew could probably have gotten the nose down again without breaking up the ship.

https://en.wikipedia.org/wiki/Air_France_Flight_447

The nature of computer/electronic information systems is such that it is generally possible to build indefinitely many levels of back-up at not too great a cost, or to build suites of tools to subject the system to brute-force testing.

Mechanical Engineering is different from Electrical Engineering, as it actually exists, because Mechanical Engineering is centered around trade-offs. I find that electrical engineers usually don’t understand thermodynamics very well. The three laws of thermodynamics are almost the opposite of Moore’s Law: You. Cannot. Do. That. Mechanical engineers find ways to edge around such laws, and circumvent them. Mechanical design really does require a nice understanding of physics, so that one can work with the forces of nature, rather than against them; and, consequently, design requires a firm command of mathematics.

The present case involves traffic light timing, and is actually a case involving Human-Factors Engineering. Civil engineers do not have a particular expertise in Human-Factors Engineering. When I was in engineering school, I took two relevant course, one in Human-Factors Engineering per se, and the other in Safety Engineering. Both of the professors belonged to the Industrial Engineering program in the Mechanical Engineering department, and the Human Factors Engineering textbook was written by a psychologist. The Human Factors Engineering was more “scientific,” in the sense of talking about general principles, with a lot of emphasis on how to design displays. A lot of human-factors work came out of the aviation industry, and involved pilots misreading instruments, or grabbing the wrong lever. The Safety Engineering course was more case-oriented, aimed at getting us to think about the crazy ways people actually behave. The professor presented and discussed a slideshow, consisting of photographs he had taken as an accident investigator. A motorcyclist had a bad accident because the handlebars of the motorcycle came loose at speed, and he couldn’t steer, things like that.

http://theinstitute.ieee.org/ieee-roundup/blogs/blog/does-having-a-license-make-you-an-engineer