Computers are essential for design and analysis, and they are also indispen-sable for controlling manufacturing, exploration, refining, and process con-trol. However, computers create unique liability issues. For example, if a key engineering or geoscience decision is based on faulty computer output, who is liable for the damage that may result? This chapter discusses professional liability for computer-generated errors, and suggests some simple procedures for validating computer software.
Computers also create new ethical problems, including vandalism, viruses, and software piracy. For example, computers are common tools for copyright infringement, perhaps because they make copying so rapid and convenient.
This chapter therefore concludes with an overview of the laws for intellectual property, including copyright, patents, industrial designs, integrated circuits, and trademarks.
T H E R O L E O F C O M P U T E R S I N E N G I N E E R I N G A N D G E O S C I E N C E
In the past 30 years, computers have drastically changed every phase of our lives, and professional practice is no exception. Recent university graduates may not realize how profound these changes have been.
A SHORT BUT AMAZING HISTORY Calculating devices such as the abacus, the slide-rule, and the adding machine have existed for centuries, but the first truly electronic computer was not built until 1945, at the end of the Second World War. The initial impetus came from the work of British mathematician Alan Turing, who developed primitive machines to assist in the decoding of German war messages at Britain’s Bletchley Park intelligence centre during the war. This early computer development is not well known because of wartime secrecy, although the story of Turing’s impressive achievements and tragic life is gripping and fascinating.1
The first computers were slow and expensive behemoths by today’s stan-dards; they filled rooms, yet they were capable of only primitive calculations.
The invention of the transistor and large-scale circuit integration (LSI) property, including copyright, patents, industrial designs, integrated circuits, and trademarks.
T H T H T H T T
T EE R OROOOOL EL EL EEE OF C OOOOOOM PM PM PM PM PM PM U TU TU TU TUTE REE RRRRRRS I NI NI NI NI NI N EN GN GN GN GN GGI NI NI NE EE RR IR IR NNN G A
A A N A N A N A A N
A DD G EGG EG O SO SC IC IC IE NE NNNC EC EC EC EC
In the past 30 years, computers have drastically changed every phase of our
permitted the miniaturization of electronic devices, and increased the relia-bility of components. A versatile personal computer (the Apple II) won over the market in 1977, and soon replaced the calculator and the slide-rule. Over the following two decades, the desktop workstation evolved, yielding immense, convenient computing power.
AN INCREDIBLE FUTURE In the 21st century, professional engineers and geosci-entists typically use desktop workstations connected to the Internet. This com-puting and communication power permits many of us to practise in areas that were at the cutting edge of research only a decade or so ago, such as earth mod-elling and visualization, computational fluid dynamics, and dynamic finite-element analysis, mechanism, and process simulation. (In fact, the common term “computer-aided design” is now out of date, since all design is now “com-puter-aided.”) Many new fields of study have developed, such as digital control, mechatronics, and nanotechnology, all based entirely on digital devices.
The computer’s incredible speed in analysis and visual design is creating a dynamic new age for engineering and geoscience. Tedious work is now done by hardware and software, freeing designers to be more creative. Today’s workstations permit ideas to be visualized, simulations to be run, and alter-natives to be analyzed in the earliest stages of any project. Calculations that were once laboriously prepared by slide-rule (and later, by calculator) are now displayed instantly, and drawings and maps that were once monotonously hand-drawn are now plotted in seconds.
However, computers are also creating new problems for professionals: prob-lems such as copyright infringement, errors caused by flaws or “bugs” in com-puter programs, vandalism by hackers and crackers, comcom-puter-aided industrial espionage, and the growing problem of identity theft. These problems sabotage productivity, so engineers and geoscientists must be alert to them.
The danger of faulty computer software was emphatically illustrated three decades ago, when the Hartford Arena collapsed—an engineering disaster that was perhaps the world’s first large-scale computer-aided failure. The arena’s design was based on an erroneous stress analysis program, as explained in Case History 9.1, which follows.
C A S E H I S T O R Y 9 . 1
T H E H A R T F O R D A R E N A R O O F C O L L A P S E : A C O M P U T E R - A I D E D FA I L U R E
The Hartford Arena was a monumentally huge structure when it was com-pleted in 1973. The arena housed a basketball court and seating for 5,000 spectators to watch the games. To minimize obstructions for spectators, only four columns supported the roof. Each column was near a corner of the building. The “space-frame” roof was a three-dimensional truss structure about 3 m (10 ft.) deep, and approximately 91 m by 110 m (300 ft. by 360 ft.) in plan size, suspended about 25 m (83 ft.) above the floor.
puter programs, vandalism by hackers and crackers, computer-aided induduuustsststriririalalala espionage, and the growing problem of identitty tthheft. These prppoblems sssabababboototagtagaa ee was perhaps the world’s first large-scale computer-aided failure. The arena’s
T h e R o o f C o l l a p s e
At 4:15 a.m. on January 18, 1978, during a heavy snowfall, the huge roof sud-denly and violently collapsed onto the central court, with the corners of the roof pointing up into the air. Fortunately, the collapse occurred in the middle of the night. Earlier in the evening, the arena had been packed with thousands of spectators, and all of them missed death or injury by a matter of a few hours.
T h e C a u s e o f t h e F a i l u r e
During the investigation, the snow load at the time of the collapse was esti-mated to be less than half the rated load for the roof. Attention shifted to the design. The detail design of the structural steel had several gross errors, as described very well in the case study by Rachel Martin, which is available on the Internet.2However, the basic cause of the collapse was, as Henry Petroski stated, an “oversimplified computer analysis.”3The Hartford Arena involved one of the earliest applications of computers to the analysis of complex space-frame structures, and the designers made a fateful error. Martin explains:
The engineers for the Hartford Arena depended on computer analysis to assess the safety of their design. Computers, however, are only as good as their pro-grammer and tend to offer engineers a false sense of security. The roof design was extremely susceptible to buckling which was a mode of failure not consid-ered in that particular computer analysis and, therefore, left undiscovconsid-ered.4 In other words, the stress analysis software overlooked the key idea that structural rods in compression buckle at a stress far lower than the yield strength of the steel, which is typically the limit for rods in tension. Any engi-neer could easily have discovered this error, at the earliest stages of the project, by comparing the stress calculated by the computer against the well-known Euler buckling equation—a simple calculation that can be performed in minutes.
E t h i c a l I m p l i c a t i o n s
Why the engineers neglected to perform such a simple, obvious check of their computer output is a mystery. Moreover, the design engineers had a very strong incentive to double-check their calculations. During the construction, the truss was assembled on the ground and hoisted into place. Large deflec-tions were immediately apparent, and the engineers were informed. In fact, as Kaminetzky reports, the deformations were so much larger than expected that contractors could not insert the windows designed to fit below the girders. Even the ironworkers reported that the deformations were unreason-ably large.5Nevertheless, the engineers ignored these warnings and did not double-check their work.
It should be clear that the actions of the design engineers were negligent or incompetent. The Hartford Arena engineers failed to validate the computer output adequately and subjugated their judgment to the computer. Computer strength of the steel, which is typically the limit for rods in tension. Any engngngi-gi- i-neer could easily have discovered this error, at the earliest stagggges ooofff ththththeee prrr
p ojoojojojojeccccct,tt,, b bbyyy coccococcommpmm arinnnnnnggg gg gththththththe e eee stsss rerereresseesssssssssss calcccccalalaalalacucccc lallalalateteteteteeed bybybybyby thy he cccomomommpupuputer ragaga aiaiainsnsnst ttthththee wew well-kn
kn kn knn kn
knnowowwnn EEEuEEEulleleeer bubuucklingngngggg e e equequququququatatatatatatiiioioioioionn—nnnn aa aaasisisimpmmpplelelelelle c c calccccaallcullatitioniionon than hah t cccac nn nbebebe p pperrfoformmmeed innnnn minmmmnnnutuuteses.
program validation should be routine due diligence. The engineers com-pounded their negligence when they ignored the excessive deflection of the truss—a warning sign that something was wrong.
The details of the case were never revealed in court. After six years of legal preparation, an out-of-court settlement was reached, and a probing discussion of the causes was therefore precluded.
An engineer or geoscientist cannot guarantee that every project will suc-ceed, just as a surgeon cannot save every patient, and a lawyer cannot win every lawsuit. However, what the engineer, geoscientist, surgeon, and lawyer must all guarantee is that they possess adequate knowledge, and that they will exercise reasonable skill, care, and expertise, appropriate to the profession, to carry out the client’s wishes. In the case of computer-aided design, reasonable care requires validation of the computer software.
L I A B I L I T Y F O R S O F T WA R E E R R O R S
Software engineers aspire to high professional standards, but computer pro-grams occasionally produce incorrect results, as the Hartford Arena collapse shows. The key question is: Who is liable if damage results from decisions based on faulty software?
Photo 9.1 — Hartford Arena Roof Collapse. The Hartford Arena was con-structed in 1973, and housed a basketball court and seating for 5,000 spectators.
On January 18, 1978, during a heavy snowfall, the huge roof suddenly collapsed, only hours after a well-attended game. The collapse was traced to an “oversimpli-fied computer analysis.” The arena is known as the first computer-aided failure.
Source: © Bettmann/CORBIS.
l d h ld b d d lll h
program validation should be routine due dillligigigengeneencee.. ThThThThe ee enenengingiggneerers ss cocom-mm p
p po
p unuununndededddd thheeeir neeegglglglglgligigiigigigigeneneneennncecceccece w w w whwwhehehehehen ennn nthththttttheyeeyyyy i iiiiigngngnggnooroedd thehehe e exce ccceessiiivevevv d ddefefefeleleleectttioion oof thehehe trr
tuuss—ss—s a wawarnrning n gggsisisisignigngngngnn t ttttthahahahahahattt tttsossosssoomemememeeeethththhhhiinngg gwawawawawawwas sswrong.gg h
The dddetails l of thef hhhh case were never revealed ddini ccoourt. AfAfAter sisixix years of llllegal preparation an out-of-court settlement was reached and a probing discussion
Almost every commercial computer program includes a disclaimer stating clearly that the manufacturer and supplier are not liable for any damage arising from the program’s use. Typically, the disclaimer specifically denies responsibility for direct or indirect damages, including loss of business profits, business interruption, personal injury, financial loss, and/or similar losses. In effect, this limits the manufacturer’s liability to the price paid for the program.
This disclaimer shifts the responsibility to the user—a fact confirmed by the provincial Associations. For example, the PEG-NL (Newfoundland and Labrador) software guideline simply states: “Members are responsible for ver-ifying that results obtained by using software are accurate and acceptable.”6
The APEGGA (Alberta) guideline states the responsibility more thor-oughly:
Members are responsible for verifying that any results obtained from computer programs are reliable and valid. Professional members should: examine and understand the method-ologies and input parameters, as well as the limitations of the results obtained; and verify, where appropriate, new software releases against a standard certified for general use.7 The PEO (Ontario) guideline defines the engineer’s responsibility even more specifically. Under the heading “Use of Computer Software Tools by Professional Engineers,” the guideline states:
The engineer must have a suitable knowledge of the engineering principles involved in the work being conducted, and is responsible for the appropriate application of these principles. When using computer programs to assist in this work, engineers should be aware of the engineering principles and matters they include, and are responsible for the interpretation and correct application of the results provided by the programs.
Engineers are responsible for verifying that results obtained by using software are accu-rate and acceptable. Given the increasing flexibility of computer software, the engineer should ensure that professional engineering verification of the software’s performance exists. In the absence of such verification, the engineer should establish and conduct suitable tests to determine whether the software performs what it is required to do.8 Clearly, all of these guidelines hold the user responsible for verifying that the software is operating properly. This means that the user must test or verify the software before using the computer output in engineering design. Such tests, typically called validation tests, require independent calculations.
Validation tests will vary, depending on the type of analysis and on whether the software was developed in-house (by the user) or was commercially pur-chased. (Typically, source code is not available for commercial software.) Let us consider these cases separately.
S O F T WA R E D E V E L O P M E N T
Professional engineers and geoscientists often develop software—for themselves, or under contract for others. In fact, the need for skilled profes-sionals in this critical field explains why software engineering is a licensed
interpretation and correct application of the results provided by the programs.
Engineers are responsible for verifying that results obtaiined bd bd bby uyy uusinng sg ssoftofofoftwarwarwware ae ae ae are re reacccu-u rat
rattee aaandnd aacacceptepteptable. GivGivGivGivGivGivveeen enen thetheththethe inh ininini crecrecccrecreasiaaasasiiing ngng ngng ng flg lllexibxibxibxibxibiliibiii ttyyy oof comcomputputputputer ee sofssos twawawarare, thththe ee ee ee engiiineeer sho
shoouldulllld ensursure te that pr pr prprpofeofeofeofofeofff ssississssisisiionononnanal eall el el elenginngingiggneneneeneeeerrinrinrinri g g verierierieririrficffifificfici aaaationn of ffththehh ssosofftwwaare’ss spereererfoforfomanmance exists. In the absence off such verififfiication, the engineer shoulh lldd estabblish anddd conductdd suitable tests to determine whether the software performs what it is required to do8
engineering discipline. When life, health, or public welfare is placed at risk, governments have a duty to regulate the discipline. Therefore, if you are developing software for internal company use, or under a software contract, or for sale to others, it is important that you follow accepted guidelines for accuracy, reliability, documentation, and testing. The first step is to specify the scope of the project; that is, to define precisely what is to be developed, and how it will be used.
Specifying the Scope of a Software Project
The PEO guideline is presently the most comprehensive provincial guideline for software development. It offers the following advice for specifying the scope of the project when negotiating contracts:
An engineer embarking on the development of engineering software for a client runs the risk of liability if the software does not perform according to the client’s requirements, or if its use causes harm to the client or the public. A well-drawn legal contract, which contemplates the development of engineering software for a client and its use by the client, can minimize the engineer’s exposure to liability.
It can also define the contractual rights and obligations between the parties to the contract. . . . [P]rovisions addressing at least the following concerns should be included in such a contract:
• What is to be developed;
• Deliverables;
• Scope of use of deliverables;
• Representations and warranties;
• Ownership;
• Limitation of liability;
• Contract price, and
• Maintenance and escrow.9
The contract terms for limiting liability are especially important. In the unlikely event that the contract should be breached, a clause limiting liability will be honoured, provided it is a thoughtful and reasonable estimate of the damages likely to result from the breach.10It is wise to consult a lawyer when you negotiate a contract with complex legal terms.
Software Testing
The PEO software guideline includes a lengthy discussion of several reviews and tests that should be followed during the software development. The fol-lowing are suggested as a minimum:
• Software requirements review;
• Software design review;
• Code review;
• Scope of use of deliverables;
• Representations and warranties;
• Ow
• OwOwwwnerererershisss p;
• LiLi
• LiLiLimitmitm attion of lialialialialialiabiabilbilbilbbilbilityityitityityity;;;;;
• Co
• Co
• Co
• Contrntrntrntractacacta pricepriceiceic, a, aaaaandndnndndd
• Maintenance and escrow.9
• Unit testing;
• System integration testing, and
• Validation testing.11
The early reviews are important because they can save much development time. Also, the final test—that is, the validation—is especially important because it is the final verification step before the software is turned over to the user. The PEO software guideline defines validation as “testing the integrated system to ensure that it meets functional and conceptual design require-ments.”12An old engineering adage puts it much more simply: “No impor-tant decision should ever be based on a single calculation.” In other words, important calculations should always be independently double-checked. This adage dates back to slide-rule days, but applies equally to computer output.
You must validate software before using it to make key decisions.
Software developers must ensure that their work follows a guideline such as the one published by PEO, or similar documentation for their province or specific discipline.
U S I N G C O M M E R C I A L S O F T WA R E
Many engineers and geoscientists use large commercial software packages for highly specialized analysis. Even commercial software may have flaws, but errors are more likely introduced by the user. For example, the user may
• use incorrect units for data input,
• apply the program to the wrong type of problem, one that is unsupported by the program theory (such as using a program intended for planar analysis in a 3-D application),
• set erroneous parameters (such as integration parameters) that result in incorrect computational accuracy,
• not understand the output display, and/or much more. In fact, users are
• not understand the output display, and/or much more. In fact, users are