By Henry Petroski from "Remaking the World"

For some time now many of the most prominent and colorful pages in Mechanical Engineering magazine have been filled with advertisements for computer software. However, there is a difference between the most recent ads and those of just a few years earlier. In 1990, for example, many software developers emphasized the reliability and ease of use of their packages, with one declaring itself the "most reliable way to take the heat, handle the pressure, and cope with the stress" while another promised to provide "trusted solutions to your design challenges".

More recent advertising copy is a bit more subdued, with fewer implied promises of that the software is going to do the work of the engineer – or take the heat or responsibility. The newer message is that the buck stops with the engineer. Software packages might provide "the right tool for the right job", but the engineer works the tool. A sophisticated system might be "the ultimate testing ground for your ideas", but the ideas are no longer the machine’s, they are the engineer’s. Options may abound in software packages, but the engineer makes a responsible choice. This is at it should be, of course, but things are not always as they should be, and that is no doubt why there have been subtle and sometimes not-so-subtle changes in technical software marketing and its implied promises.

Civil Engineering has also run software advertisements, albeit less prominent and colorful ones. Their messages, explicit or implicit, are more descriptive than promising, Nevertheless, the advertisements also contain few caveats about limitations, pitfalls or downright errors that might be encountered in using prepackaged, often general-purpose software for a specific engineering design or analysis. The implied optimism of the software advertisements stands in sharp contrast to the concerns about the use of software that have been expressed with growing frequency in the pages of the same engineering magazines.

The American Society of Civil Engineers, publisher of Civil Engineering and a host of other technical journals and publications full of theoretical and applied discussions of computers and their uses, has among its many committees one on "guidelines for avoiding failures caused by misuse of civil engineering software." The committee’s parent organization, the Technical Council on Forensic Engineering, was the sponsor of a cautionary session on computer use at the society’s 1992 annual meeting, and one presenter titled his paper, "Computers in Civil Engineering: A Time Bomb!" In simultaneous sessions at the same meeting, other equally fervid engineers were presenting computer-aided designs and analyses of the future.

There is no doubt that computer-aided design, manufacturing and engineering have provided benefits to the profession and to humankind. Engineers are attempting and completing more complex and time-consuming analyses that involve many steps (and therefore opportunities for error) and that might not have been considered practicable in slide-rule days. New hardware and software have enabled more ambitious and extensive designs to be realized, including some of the dramatic structures and ingenious machines that characterize the late twentieth century. Today’s automobiles, for example, possess better crashworthiness and passenger protection because if advanced finite-element modeling, in which a complex structure such as a stylish car body is subdivided into more manageable elements, much as we might construct a gracefully curving walkway out of a large number of rectangular bricks.

For all the achievements made possible by computers, there is growing concern in the engineering design community that there are numerous pitfalls that can be encountered using software packages, All software begins with some fundamental assumptions that translate to fundamental limitations, but these are not always displayed prominently in advertisements. Indeed, some of the limitations of software may be unknown to the vendor and the customer. Perhaps the most damaging limitation that it can be misused or used inappropriately by an inexperienced or overconfident engineer.

The surest way to drive home the potential dangers of misplaced reliance on computer software is to recite the incontrovertible evidence of failures of structures, machine, and systems that are attributable to use or misuse of software. One such incident occurred in the North Sea in August 1991, when the concrete base of a massive Norwegian oil platform, designated Sleipner A, was being tested for leaks and mechanical operation prior to being mated with its deck.

The base consisted of a structure of two dozen circular cylindrical reinforced-concrete cells. Some of the cells were to serve as drill shafts, other as storage tanks for oil, and the remainder as ballast tanks to place and hold the platform on the sea bottom. Some of the tanks were being filled with water when the operators heard a loud bang, followed by significant vibrations and the sound of a great amount of running water. After eight minutes of trying to control that water intake, the crew abandoned the structure. About eighteen minutes after the first bang was heard, Sleipner A disappeared into the sea, and forty five seconds later a seismic event that registered a 3 on the Richter scale was recorded in Norway. The event was the massive concrete base striking the sea floor. An investigation of the structural design of Sleipner A’s base found that the differential pressure on the concrete walls was too great where three cylindrical shells met and made left a triangular void open to he full pressure of the sea. It is precisely in the vicinity of such complex geometry that computer-aided analysis can be so helpful, but the geometry must be modeled properly. Investigators found that "unfavorable geometrical shaping of some finite elements in the global analysis … in conjunction with the subsequent post-processing of the analysis results … led to the underestimation of the shear forces at the wall supports by some 45%." (Whether or not due to the underestimation of stresses, inadequate steel reinforcement also contributed to the weakness of the design.) In short, no matter how sound and reliable he software may have been, its improper and incomplete use led to a structure that was inadequate for the loads to which it was subjected.

In its November 1991 issue, the trade journal Offshore Engineer reported that the errors in analysis of Sleipner A "should have been picked up by internal control procedures before construction started." The investigators also found that "not enough attention was given to the transfer of experience from previous projects." In particular, trouble with an earlier platform, Statfjord A, which suffered cracking in the same critical area, should have drawn attention to the flawed detail. (A similar neglect of prior experience occurred, of course, just before the fatal Challenger accident, when the importance of previous O-ring problems was minimzed.)