Engineering Ethics

Every electronic product carries decisions that its users cannot see. A patient cannot inspect the firmware that limits an infusion pump's dose, a driver cannot check how emission controls behave on the road, and a passenger cannot review the assumptions behind a flight control law. They rely on engineers to make such decisions competently and to report them honestly. Engineering ethics is the discipline of honoring that reliance: the obligations engineers accept toward the public, toward their employers and clients, and toward one another, and the judgment needed when those obligations collide.

Professional and licensing bodies write these obligations down as codes of ethics. The codes of the IEEE, the National Society of Professional Engineers (NSPE), the National Council of Examiners for Engineering and Surveying (NCEES), and national bodies in Canada, the United Kingdom, and Australia differ in wording and legal force, but they share a core. Public safety comes first, engineers work within their competence, engineering statements are truthful, conflicts of interest are disclosed, and concerns about danger are raised rather than buried.

This article explains why ethics belongs inside engineering practice, what the principal codes say in their current published versions, and how they apply to test data, conflicts of interest, confidentiality, intellectual property, dissent, and software in safety functions. Three case studies, each drawn from a primary or authoritative investigation, show the obligations failing in practice: the Therac-25 radiation therapy accidents, the Volkswagen emissions defeat device, and the Boeing 737 MAX. Where the article names a statute, it states the jurisdiction. It describes principles and is not legal advice.

Why Ethics Is Part of Engineering Practice

Engineering differs from many occupations in who bears the cost of a mistake. A defective power supply design harms the family whose home catches fire. The people exposed to engineering risk usually cannot evaluate it, so they depend on engineers to evaluate it for them. That dependence is the foundation of every engineering code.

Licensing law rests on the same idea. The NCEES Model Law, the model statute that NCEES offers to U.S. licensing jurisdictions, opens in section 110.10 by declaring engineering practice subject to regulation "in order to safeguard the health, safety, and welfare of the public."

Ethics and law overlap without coinciding. Law sets minimum requirements and tends to trail new technology, so an ethical engineer asks whether a design is safe and honest, not only whether it passes. The 2020 final report on the Boeing 737 MAX prepared by the majority staff of the U.S. House Committee on Transportation and Infrastructure called the fact that "a compliant airplane suffered from two deadly crashes in less than five months" clear evidence that the regulatory system is "fundamentally flawed."

Ethical failures rarely look abstract. They usually take the form of technical decisions: a protective function that depends on one sensor, a hardware interlock removed because software is expected to catch the fault, or an algorithm that behaves differently when it detects a test. Recognizing the ethical content of such decisions is part of technical competence. Engineers make these decisions inside organizations with schedules, budgets, and incentives, but the codes still address individuals. NSPE's code notes that professional services "must be performed by real persons." Engineering Profession traces how the societies and licensing systems behind the codes developed.

The Codes and Who Publishes Them

Engineering codes come from three kinds of bodies. Membership societies bind their members. Licensing authorities bind licensees in their jurisdictions. National professional bodies in several countries combine registration or regulation with ethical guidance. The table lists the codes discussed here with the version each owner shows.

Engineering codes discussed in this article
Owner	Document	Version shown by the owner	Whom it addresses
IEEE	IEEE Code of Ethics (IEEE Policies, section 7.8)	Revisions through June 2020	IEEE members
National Society of Professional Engineers	Code of Ethics for Engineers	Revised July 2019	Engineers, with NSPE members expected to live up to it
National Council of Examiners for Engineering and Surveying	Model Law; Model Rules, including section 240.15	Both revised August 2025	U.S. legislatures and licensing boards, as models that bind only where a jurisdiction adopts them
Engineers Canada	Guideline on the code of ethics	July 2024	Provincial and territorial regulators, whose own codes bind their registrants
Engineering Council and Royal Academy of Engineering	Statement of Ethical Principles	February 2026	Engineers, technologists, and technicians, as principles rather than rules
Engineers Australia	Code of Ethics and Guidelines on Professional Conduct	August 2022	Members of Engineers Australia

IEEE Code of Ethics

The IEEE Code of Ethics is section 7.8 of the IEEE Policies, and the text on the IEEE website states that it incorporates revisions through June 2020. Its ten commitments sit under three headings: integrity and responsible conduct in professional activities, fair and respectful treatment of all persons, and helping colleagues uphold the code. The first commitment is "to hold paramount the safety, health, and welfare of the public." The same item joins that duty to ethical design and sustainable development practices, protection of the privacy of others, and prompt disclosure of factors that might endanger the public or the environment. Later items cover public understanding of emerging technologies "including intelligent systems," conflicts of interest, unlawful conduct and bribery, honest criticism and correction of errors, technical competence, discrimination and harassment, and a commitment not to retaliate against people who report violations.

NSPE Code of Ethics for Engineers

NSPE's code, revised July 2019, rests on six Fundamental Canons. Engineers shall hold paramount the safety, health, and welfare of the public; perform services only in areas of their competence; issue public statements only in an objective and truthful manner; act for each employer or client as faithful agents or trustees; avoid deceptive acts; and conduct themselves honorably, responsibly, ethically, and lawfully. Rules of Practice and Professional Obligations make the canons specific. One rule requires an engineer whose judgment is overruled "under circumstances that endanger life or property" to notify the employer or client "and such other authority as may be appropriate."

NCEES Model Law and Model Rules

NCEES is the organization through which the engineering and surveying licensing boards of the U.S. states and territories act together. Its Model Law is model enabling legislation that defines a licensing board's powers and duties, and its Model Rules are model board regulations that carry out the law; both carry an August 2025 revision date. Section 240.15 of the Model Rules groups the rules of professional conduct into obligations to the public, to employers and clients, and to other licensees. It begins by requiring licensees to be cognizant that their "first and foremost responsibility is to safeguard the health, safety, and welfare of the public." Section 150.10 of the Model Law lets a board reprimand, fine, suspend, or revoke a license on grounds that include negligence, incompetence, or misconduct; knowingly making or signing false statements, certifications, or affidavits; and providing services outside the licensee's areas of competence. Each jurisdiction enacts its own statute and rules, which may differ from the models.

Codes Outside the United States

In Canada, engineering is regulated under provincial and territorial law. Engineers Canada's Guideline on the code of ethics, dated July 2024, synthesizes the regulators' codes into 13 principles, which each regulator may adopt in whole, in part, or not at all. It is explicit about how to escalate a safety concern and about an engineer's responsibility for the outputs of tools such as artificial intelligence, and it states that it does not establish a legal standard of care. In the United Kingdom, the Engineering Council and the Royal Academy of Engineering publish a joint Statement of Ethical Principles, first published in 2005, revised in 2017, and updated in a version dated February 2026. Its five principles are honesty and integrity, responsibility to society, "accuracy and rigour," leadership and communication, and responsibility for the future of technology, society, and the environment. The statement calls these principles rather than rules and relies on the institutions of the profession for detailed codes of conduct. Engineers Australia's Code of Ethics and Guidelines on Professional Conduct, dated August 2022, groups its commitments under four headings: demonstrate integrity, "practise competently," exercise leadership, and promote sustainability.

The Paramountcy of Public Safety

Every code examined here puts the public first. The IEEE and NSPE codes say "hold paramount," and the NCEES Model Rules speak of a licensee's "first and foremost responsibility." Engineers Canada explains the word: "paramount" means that all other requirements of the code are subordinate when public safety, the environment, or other substantive public interests are involved. The UK statement asks engineering professionals to make the health and safety of others a leading priority and to draw attention to hazards.

Paramountcy settles conflicts between duties. Engineers owe employers loyalty and clients confidentiality, but neither duty extends to concealing a danger to the public. Engineers Canada states that exception within its principle on acting as a faithful agent.

Paramountcy does not mean zero risk. Every product carries residual risk, and much of engineering consists of reducing risk to a level that users, regulators, and society accept. The obligation is to identify hazards honestly, reduce them as far as is reasonable, and state plainly the risk that remains. The UK statement asks engineering professionals to "acknowledge and communicate uncertainty, limits of evidence, and unknowns." A risk that was never disclosed was never accepted by the people who bear it.

In daily work, the principle appears in ordinary decisions: refusing to ship firmware with an unresolved hazard because a trade show is next week, insisting that a pattern of field failures be investigated rather than closed as "no fault found," or declining to approve a design review that lacks its safety analysis. Such decisions cost time and money.

Competence and Working Within It

NSPE's second canon limits engineers to services in areas of their competence. The IEEE code permits members to undertake technological tasks for others only if qualified by training or experience "or after full disclosure of pertinent limitations." The NCEES Model Rules forbid licensees to sign or seal documents on subjects in which they lack competence, and the Model Law makes practice outside a licensee's areas of competence a ground for discipline.

Competence is specific to the task. An excellent digital designer may have no basis for judging insulation coordination in mains-powered equipment, radio-frequency exposure from a wearable transmitter, or the integrity requirements of a safety function. Leveson and Turner put the point bluntly in their Therac-25 investigation: "Taking a couple of programming courses or programming a home computer does not qualify anyone to produce safety-critical software." Titles do not confer competence either. Engineers Canada warns that a title such as director of engineering is ethical only if its holder can remain adequately aware of the engineering activities and decisions made throughout the organization.

Working within competence takes several practical forms:

Say so. When an assignment exceeds your competence, tell the person who assigned it and propose a remedy: a specialist, training, or supervision by someone qualified.
Disclose the unknown. Where the required knowledge does not exist, Engineers Canada advises proceeding only with full disclosure to all parties involved.
Approve only what you can check. Engineers Canada ties responsibility to work "for which they can validate outputs used in its development."
Keep learning. Every code in this article includes an obligation to maintain competence.

Competence includes knowing the limits of tools. Simulation models and design automation produce answers that look authoritative whether or not their assumptions hold. Engineers Canada applies the same reasoning to artificial intelligence: "a registrant is still ultimately responsible for the outputs," and a tool whose work cannot be verified and validated puts the public at significant risk.

Honesty in Test Data, Reports, and Certification

People rely on engineering statements because they cannot repeat the work. A test report, a reliability prediction, a datasheet limit, and a declaration of conformity each tell someone else what is true about a product. NSPE requires engineers to be objective and truthful in professional reports, statements, and testimony, to "include all relevant and pertinent information," and not to "distort or alter the facts." Under the NCEES Model Law, knowingly making or signing false statements, certifications, or affidavits is a ground for discipline. Engineers Canada adds a useful habit: distinguish facts, assumptions, and opinions, and test conclusions built on assumed parameters with sensitivity analyses.

Outright fabrication is rare. The common failures are quieter:

Reporting the passing sample and omitting the failures, or retesting until a result passes without recording the earlier runs.
Changing a pass criterion after seeing the data.
Testing a hand-tuned unit and presenting the result as representative of production.
Quoting a reliability or battery-life figure without the conditions under which it holds.
Signing a compliance declaration on the strength of an informal pre-scan, a supplier's assurance, or a report on a different hardware revision.
Designing a product to recognize test conditions and behave differently during the test.

The last is the most serious, because it turns an honest test into a deception. It is also unmistakably engineering work: someone must specify, implement, calibrate, and verify the detection logic. The Volkswagen case study below shows how the U.S. Environmental Protection Agency characterized such software.

Sound data practice makes honesty easier to sustain. Define pass criteria before testing. Keep raw data, not only summaries. Record every retest and its reason. Tie each report to the exact hardware, firmware, and test-setup revision, and give an independent reviewer access to the evidence behind any safety or compliance claim.

Conflicts of Interest, Gifts, and Confidentiality

Conflicts of Interest

A conflict of interest exists when a personal, financial, or organizational interest could influence, or appear to influence, professional judgment. The IEEE code asks members to avoid real or perceived conflicts "whenever possible, and to disclose them to affected parties when they do exist." The NCEES Model Rules require licensees to disclose "all known or potential conflicts of interest" to their employers or clients. Engineers Canada adds that disclosure should come without delay and that, when full disclosure is insufficient to protect all parties' interests, the engineer should withdraw totally from the issue or use extraordinary means, involving independent parties if possible, to monitor the situation.

Electronics work produces recognizable conflicts. An engineer who owns shares in a supplier evaluates its parts. A consultant reviews one client's design while advising a competitor. A designer is asked to serve as the independent assessor of a safety case for a product the designer helped create. None of these automatically makes the work wrong, but each must be disclosed so that someone else can judge whether the work can be trusted. Some conflicts are structural rather than personal: the House committee found that the FAA's oversight structure with respect to Boeing "creates inherent conflicts of interest." Engineers who serve as expert witnesses face a related duty of objectivity, described in Legal and Litigation Support.

Gifts and Inducements

Gifts create a sense of obligation, which is why they are given. NSPE forbids engineers to accept "financial or other considerations, including free engineering designs, from material or equipment suppliers for specifying their product." The NCEES Model Rules bar licensees from soliciting or accepting gratuities in connection with work for employers or clients, and the IEEE code commits members "to reject bribery in all its forms." The concern is consideration tied to a decision. Application notes and reference designs that a supplier publishes for every customer are ordinary technical information; a private reward for designing in a particular part is not. When in doubt, disclose the offer and ask.

Confidentiality

Engineers routinely hold information that belongs to others, from a client's product plans to a supplier's failure analysis. NSPE and the NCEES Model Rules prohibit revealing such information without prior consent unless law or the governing code or rules authorize or require disclosure, and NSPE extends the duty to former clients and employers. Confidentiality is not a license to hide danger, however. Engineers Canada advises that, when the public is at risk, the engineer should first try to have the client or employer correct the situation before escalating to regulators or the public, while still respecting confidential and proprietary information.

Intellectual Property Obligations

Electronics engineers build on schematics, source code, IP cores, and published research every day, so intellectual property is a practical ethical subject for them. The NCEES specification for the Fundamentals of Engineering exam in electrical and computer engineering, effective with the July 2020 examinations, lists intellectual property under ethics and professional practice, naming copyright, trade secrets, patents, and trademarks.

The four forms protect different things. A patent gives its owner a time-limited right to exclude others from an invention in exchange for disclosing it. Copyright protects original expression, including source code and documentation. A trade secret is valuable information protected by being kept secret, such as a calibration method or a process recipe. A trademark protects the names and marks that identify the source of a product. Terms and remedies vary by country.

The codes turn these legal categories into personal duties:

Give credit. The IEEE code commits members "to credit properly the contributions of others," and NSPE asks engineers to name, whenever possible, the people individually responsible for designs, inventions, and writings. The UK statement counts plagiarism among the corrupt practices that engineering professionals must take steps to prevent.
Respect ownership. NSPE treats designs, data, records, and notes referring exclusively to an employer's work as the employer's property, and it asks engineers to agree on ownership before undertaking work that may justify patents or copyrights. The UK statement asks engineering professionals to respect intellectual property.
Leave a former employer's secrets behind. NSPE's confidentiality duty covers former employers and clients, and Engineers Canada warns against using a previous employer's or client's proprietary information without consent. Changing jobs is not a reason to take schematics, source code, or test data.
Honor license terms. IP cores, software libraries, and open-source components carry conditions, such as attribution or publication of source code. Ignoring those conditions uses someone else's work on terms its owner never granted. Intellectual Property Management covers the practice for semiconductor IP.

When a team must build a product that competes with a former employer's design, clean-room development is one established safeguard: the implementing engineers work only from a functional specification, never see the protected material, and document the process so that independent creation can be shown. A clean room guards against copying, not against patents, which an independently developed design can still infringe. Whether reverse engineering a particular product is lawful depends on the jurisdiction and on any license agreement, so it is a question to settle with counsel before the work starts.

Dissent, Escalation, and Whistleblowing

When an engineer believes that a decision endangers people or breaks the law, the codes require more than private disagreement. NSPE requires an engineer whose judgment is overruled where life or property is endangered to notify the employer or client and other appropriate authority. If a client or employer insists on plans or specifications that do not conform to applicable engineering standards, NSPE requires the engineer to notify the proper authorities and withdraw from further service on the project. The NCEES Model Rules contain a similar duty to notify. NSPE and the Model Rules also require engineers to report known violations of the code and of licensing law, respectively. Engineers Canada describes a sequence: raise the problem with the supervisor or employer, then advise the client or inform the most senior officer, and finally present the concerns to the regulator, "even at the risk of loss of employment."

The codes also bind the people around a dissenter. The IEEE code commits members "to not retaliate against individuals reporting a violation," and the UK statement asks engineering professionals to "report malpractice and irresponsible or unsafe practice" and to "foster a culture where concerns can be raised without fear of reprisal, and act on well-founded concerns." An organization that punishes the messenger teaches everyone else to stay silent. The House committee's 737 MAX report cited a draft safety culture survey of the FAA's Aviation Safety Organization in which 34 percent of responding employees named "fear of retribution" as one reason employees do not report safety issues.

A Practical Escalation Path

Check the facts. Confirm the hazard or violation with data, analysis, or a colleague's review, and separate what you know from what you infer.
Write it down. Send the person who can act a dated, factual description of the concern, the evidence, the possible consequences, and your recommendation.
Use formal channels. Safety review boards, quality escalation procedures, ethics offices, and confidential reporting lines exist for this purpose. Keep copies of what you submit and when.
Escalate within the organization. If the response does not address the danger, take the concern to higher management.
Get independent advice. Before reporting outside the organization, consult your professional body and a lawyer who practices in the relevant jurisdiction.
Report externally when internal routes fail. The usual recipient is the regulator or licensing board with authority over the hazard. Public disclosure is a last resort, and legal protection for it may differ from protection for a report to a regulator.

The sequence is not rigid. An imminent danger may justify going to the responsible authority at once, and internal channels offer little when the people who would receive the report are the ones responsible for the problem.

Legal Protection Depends on Jurisdiction

Codes state duties, but they do not protect anyone from retaliation. Protection comes from statutes, and it differs widely between jurisdictions and sectors. The examples below are neither complete nor legal advice.

United States (federal law). The Occupational Safety and Health Administration (OSHA) enforces the whistleblower provisions of more than 20 federal laws, each with its own coverage and complaint deadline. An aviation safety provision enacted in the Wendell H. Ford Aviation Investment and Reform Act for the 21st Century (AIR21) and later amended, 49 U.S.C. § 42121, protects employees of holders of certain FAA certificates, including air carriers and aircraft manufacturers, and of their contractors, subcontractors, and suppliers, and it allows 90 days to file a complaint. A motor vehicle safety provision enacted in the Moving Ahead for Progress in the 21st Century Act (MAP-21), 49 U.S.C. § 30171, protects employees of motor vehicle manufacturers, part suppliers, and dealerships, and it allows 180 days to file. State laws may provide additional protection.
Great Britain. The Public Interest Disclosure Act 1998 inserted Part IVA into the Employment Rights Act 1996. Section 43B, as amended, defines a "qualifying disclosure" as a disclosure of information that, in the reasonable belief of the worker making it, is made in the public interest and tends to show one of several listed matters. They include a criminal offense, a failure to comply with a legal obligation, danger to the health or safety of any individual, and damage to the environment, whether past, present, or likely, and the deliberate concealment of information about any of them. The Enterprise and Regulatory Reform Act 2013 added the public interest requirement. The section extends to England and Wales and to Scotland.
European Union. Directive (EU) 2019/1937 of October 23, 2019, the Whistleblower Protection Directive, sets common minimum standards for protecting people who report breaches of the Union acts listed in its annex, in areas that include product safety and compliance, transport safety, protection of the environment, public health, and consumer protection. Member states had until December 17, 2021, to transpose it, so the rules that apply to a particular engineer are those in national law.

Protection often turns on details: what a report concerned, to whom it went, whether the belief behind it was reasonable, and how quickly a complaint followed any retaliation. Engineers Canada cautions registrants against entering legal arrangements that compromise their obligation to report. Regulatory Investigation Support describes further U.S. statutes from an employer's perspective.

Software and AI in Safety Functions

A growing share of the safety functions in electronic products runs in software: torque limits in motor drives, cutoffs in battery management systems, dose controls in medical devices, and flight control laws. Software does not wear out; its faults are designed in and wait for the conditions that expose them. Leveson and Turner observed that "virtually all complex software can be made to behave in an unexpected fashion under certain conditions." Testing cannot exercise every state of a complex program, so confidence must also come from disciplined development, analysis, and protection at the system level.

The engineer's duties here follow from the general ones:

Classify safety functions honestly. Standards such as IEC 61508, ISO 26262 for road vehicles, IEC 62304 for medical device software, and DO-178C for airborne software scale development rigor to the consequences of failure, but only for functions that are identified and classified correctly. The House committee found that Boeing failed to classify MCAS as a safety-critical system, a classification that would have attracted greater FAA scrutiny.
Avoid single points of failure in protection. Leveson and Turner concluded that software "should not be assigned sole responsibility for safety." The House committee found that Boeing permitted MCAS to activate on input from a single angle-of-attack sensor.
Test assumptions about people. The committee reported that Boeing's own test data showed a test pilot taking more than 10 seconds to respond to uncommanded MCAS activation in a simulator, a condition the pilot found "catastrophic," while federal guidelines assume a response within four seconds.
Do not treat reused software as proven. The Therac-25 reused routines from earlier machines that had independent hardware safety features. Leveson and Turner warned that "reusing software modules does not guarantee safety in the new system to which they are transferred."
Question the risk numbers. The Therac-25 fault tree assigned the event "computer selects wrong energy" a probability of 10⁻¹¹, and Leveson and Turner noted that the analysis gave no justification for the number. They wrote that engineers "should insist that any risk assessment numbers used are in fact meaningful."
Make faults visible. Cryptic error codes and missing logs hide the evidence that could prevent the next accident. Leveson and Turner recommended audit trails and incident-analysis procedures applied "whenever they find any hint of a problem that might lead to an accident."

Machine learning adds a difficulty, because a learned component's behavior comes from data rather than from a line-by-line specification, which makes conventional verification harder. The duties do not change. The engineer who places a learned component in a safety function remains responsible for the behavior of the system, including its behavior on inputs unlike the training data. The 2026 UK statement asks engineering professionals to consider fully "the risks and ethical implications of emerging and fast-moving technologies, such as artificial intelligence and technologies with autonomous or semi-autonomous capabilities."

IEC 61508, ISO 26262, and DO-178C are covered in Software Safety Standards (Beyond Medical), and the analysis methods in Hazard Analysis and Risk Assessment for Embedded Systems. Governance frameworks for AI systems, such as the EU AI Act and the NIST AI Risk Management Framework, are the subject of Digital Ethics and AI Governance.

Case Study: The Therac-25 Accidents

The Therac-25 was a computer-controlled medical linear accelerator, built by Atomic Energy of Canada Limited (AECL), that could treat patients with X-rays or electron beams. This account follows Nancy Leveson and Clark Turner, "An Investigation of the Therac-25 Accidents," published in IEEE's Computer in July 1993 and drawn, the authors state, from official FDA documents and internal memos, lawsuit depositions, letters, and other sources. The authors stated that their goal was "to help others learn from this experience, not to criticize the equipment's manufacturer or anyone else."

Eleven machines were installed, five in the United States and six in Canada. Between June 1985 and January 1987, six known accidents involved massive overdoses, with resulting deaths and serious injuries. The earlier Therac-20 had independent protective circuits and mechanical interlocks. The Therac-25 relied more on software for those functions, and AECL decided not to duplicate all of the existing hardware safety mechanisms. AECL's March 1983 safety analysis, a fault tree, "apparently excluded the software," in the authors' words; one of its stated assumptions was that "any residual software errors are not included in the analysis."

The software contained race conditions, faults whose effect depends on the timing of concurrent tasks. At the East Texas Cancer Center in Tyler, Texas, on March 21 and April 11, 1986, an experienced operator edited prescriptions quickly, the machine displayed "Malfunction 54," and patients received massive overdoses. A sheet on the machine described the message only as a "dose input 2" error, and the center had no other documentation explaining it. After the second of these accidents, the hospital physicist worked with the operator and found that editing speed was the key to reproducing the error. A different flaw caused a second accident in Yakima, Washington, on January 17, 1987. A one-byte variable incremented on each pass through a setup routine rolled over to zero on every 256th pass, and when the operator pressed the set button at that moment, a check of the upper collimator position was skipped.

The organizational response is the ethical core of the case. After an overdose in Hamilton, Ontario, in July 1985, AECL modified the machine and told hospitals that its analysis of the hazard rate indicated an improvement of at least five orders of magnitude, a claim the authors judged exaggerated, especially since AECL's final incident report to the FDA could not be firm on the exact cause. After the first Yakima overdose, in December 1985, an AECL technical support supervisor wrote to the hospital that "this damage could not have been produced by any malfunction of the Therac-25 or by any operator error." After the first Tyler accident, according to the hospital physicist, AECL personnel told him that AECL knew of no accidents involving radiation overexposure by the Therac-25; the authors found this odd, since AECL was surely aware at least of the Hamilton and Yakima accidents. An operator involved in one of the overdoses testified that she had become insensitive to machine malfunctions, which were commonplace and mostly did not involve patient safety.

The U.S. Food and Drug Administration declared the Therac-25 defective in May 1986 and required a corrective action plan. In February 1987, after the second Yakima accident, the FDA asked AECL to recommend that the machine not be used for routine therapy until an amended plan was complete, and Canada's Health Protection Branch acted similarly. The fifth and final revision of the plan, issued in July 1987, listed more than 20 hardware and software changes, among them an independent hardware single-pulse shutdown.

Leveson and Turner identified contributing factors well beyond any single coding error, including "management inadequacies and lack of procedures for following through on all reported incidents," "overconfidence in the software and removal of hardware interlocks," and "unrealistic risk assessments along with overconfidence in the results of these assessments." For practicing engineers, the case shows that holding public safety paramount includes investigating reports that contradict one's beliefs about a product, stating risk honestly, and keeping independent protection against the most severe hazards. Product Safety Failures places the accidents in a wider history.

Case Study: The Volkswagen Emissions Defeat Device

On September 18, 2015, the U.S. Environmental Protection Agency (EPA) issued a notice of violation of the Clean Air Act to Volkswagen AG, Audi AG, and Volkswagen Group of America. The notice stated EPA's determination that the companies had manufactured and installed defeat devices in certain model year 2009 through 2015 diesel light-duty vehicles with 2.0-liter engines. A notice of violation sets out an agency's allegations, and this account follows its wording.

According to the notice, software in the vehicles' electronic control module, which EPA called the "switch," sensed whether the vehicle was being tested. Its inputs included steering wheel position, vehicle speed, the duration of engine operation, and barometric pressure, inputs that EPA said "precisely track the parameters of the federal test procedure." During testing, the module ran a calibration that produced compliant results. At other times it ran what EPA termed a "road calibration," which reduced the effectiveness of the emission control system. EPA stated that emissions of nitrogen oxides increased by a factor of 10 to 40 above compliant levels, depending on the drive cycle.

The notice also recounted how the problem surfaced. In May 2014, West Virginia University's Center for Alternative Fuels, Engines & Emissions published a study, commissioned by the International Council on Clean Transportation, that found significantly higher in-use emissions from two of the vehicles, a 2012 Jetta and a 2013 Passat. For about a year afterward, according to EPA, Volkswagen attributed the higher emissions to various technical issues and unexpected in-use conditions. EPA wrote that only after it became clear that the agencies would not certify the company's 2016 model year diesel vehicles until the anomalous emissions were explained did Volkswagen admit to a defeat device "in the form of a sophisticated software algorithm that detected when a vehicle was undergoing emissions testing."

EPA's later record states that on January 11, 2017, Volkswagen agreed to plead guilty to three criminal felony counts, and that three partial civil settlements resolved allegations concerning approximately 590,000 model year 2009 to 2016 diesel vehicles, a total that includes vehicles with 3.0-liter engines. Under the third partial settlement, as EPA describes it, Volkswagen will ensure that "the personnel who test their vehicles for emissions compliance are separate from the personnel who design their vehicles," and it will establish a whistleblower system.

For engineers, the case shows how a deception can be assembled from ordinary engineering tasks. The certification process depends on disclosure: according to the notice, a manufacturer's application must list every auxiliary emission control device and give a rationale for why it is not a defeat device. Logic that recognizes a test is therefore a warning sign for anyone asked to build or review it. NSPE requires engineers to avoid deceptive acts, and the NCEES Model Law makes conduct "likely to deceive, defraud, or harm the public" a ground for discipline. The separation of test and design personnel reflects a broader principle: verification is more credible when it is independent of the design it checks.

Case Study: The Boeing 737 MAX and MCAS

Two Boeing 737 MAX airplanes crashed less than five months apart: Lion Air flight 610 on October 29, 2018, killing all 189 passengers and crew, and Ethiopian Airlines flight 302 on March 10, 2019, killing all 157. In September 2020, the U.S. House Committee on Transportation and Infrastructure released its Final Committee Report: The Design, Development & Certification of the Boeing 737 MAX, prepared by the committee's majority staff for Chair Peter A. DeFazio and Aviation Subcommittee Chair Rick Larsen after an 18-month investigation. The findings below are the committee's.

The report places the Maneuvering Characteristics Augmentation System (MCAS), a new flight control feature, at the center of scrutiny for both crashes. According to the report, Boeing developed MCAS to address stability issues in certain flight conditions induced by the airplane's larger engines and their placement. MCAS could move the horizontal stabilizer to push the nose down, and it operated on input from one of the airplane's two angle-of-attack sensors. The report concludes that faulty angle-of-attack data that repeatedly triggered MCAS played critical roles in both crashes.

The committee organized its conclusions around five themes:

Production pressures. Financial pressure to compete with the Airbus A320neo led to efforts to cut costs, hold the program schedule, and avoid slowing the production line, and the committee identified several instances in which those goals jeopardized safety.
Faulty design and performance assumptions. Boeing permitted MCAS to activate on a single sensor's input, expected pilots who were largely unaware of the system to mitigate a malfunction, and did not classify MCAS as safety-critical.
Culture of concealment. The report states that Boeing withheld crucial information from the FAA, its customers, and pilots, including concealing the existence of MCAS from pilots and failing to disclose that the AOA Disagree alert was inoperable on the vast majority of the fleet.
Conflicted representation. Boeing Authorized Representatives, employees permitted to act on the FAA's behalf in validating compliance, in several instances failed to disclose important information to the agency.
Boeing's influence over the FAA's oversight structure. Career FAA officials documented examples in which FAA management overruled the agency's own technical experts at Boeing's behest.

Several findings bear on individual conduct. The report describes a 2016 Boeing survey in which 39 percent of responding Authorized Representatives perceived "undue pressure" and 29 percent were concerned about consequences if they reported it. It describes a representative who raised concerns internally in 2016 about pilots' ability to respond to repetitive MCAS activation and about the effect of faulty angle-of-attack data; according to the report, those concerns were not properly addressed, and the representative did not inform the FAA. It also describes a 2013 request by a Boeing engineer for a synthetic airspeed indicator, which management rejected because of cost and because it could have jeopardized the program's directive to avoid pilot simulator training requirements. The committee noted that not all of the instances involving Authorized Representatives violated FAA regulations or guidance, and it recorded that Boeing and the FAA had suggested that the certification complied with FAA regulations.

For engineers, the case shows why compliance cannot substitute for judgment, why assumptions about human response must be tested rather than asserted, why a person exercising delegated authority owes candor to the authority that delegated it, and why an organization's willingness to hear bad news is itself a safety feature.

Ethics Across the Product Lifecycle

Ethical obligations do not end when a design is released. The UK statement asks engineering professionals to "manage technology responsibly across its lifecycle, including decommissioning," and Engineers Canada asks registrants to monitor and report the consequences of their projects. The table pairs each stage of an electronic product's life with typical questions and the provisions that speak to them.

Ethical questions across the life of an electronic product
Stage	Questions to ask	Where the codes and investigations speak
Concept and requirements	Who could be harmed, including people who never buy the product? What misuse is foreseeable?	The paramountcy of public safety in every code; the UK statement on anticipating potential misuse
Design	Does a single sensor, processor, or software routine stand between a fault and a hazard? Are privacy and security designed in?	The IEEE commitment to protect the privacy of others; Leveson and Turner on single points of failure
Verification and certification	Were pass criteria fixed before testing? Does each declaration rest on evidence for the revision that ships?	NSPE on objective and truthful reports; the NCEES Model Law on false statements and certifications
Manufacturing and supply	Has a substituted component or changed process been requalified? Are counterfeit parts kept out?	NSPE on approving only engineering documents that conform to applicable standards
Marketing and sales	Do performance claims stay within tested conditions?	NSPE on statements that misrepresent or omit a material fact
Field operation	Are returns, complaints, and incident reports investigated? Are vulnerabilities disclosed and fixed?	Engineers Canada on monitoring and reporting consequences; Leveson and Turner on incident analysis
End of life	Will users know when support ends? Are data and hazardous materials handled responsibly?	The UK statement on managing technology through decommissioning

Two stages deserve emphasis because their failures are easy to rationalize. In field operation, a product generates evidence through returns, complaints, service records, telemetry, and vulnerability reports, and the Therac-25 history shows what happens when such evidence is explained away. Vulnerabilities call for a process like the one described in Coordinated Vulnerability Disclosure, and a confirmed hazard in products already sold calls for correction, as described in Product Recall Management. In manufacturing and supply, a substituted component, a changed process, or a counterfeit part can quietly invalidate the qualification on which safety claims rest; Counterfeit Component Prevention addresses the last of these.

Conclusion

Engineering ethics is not an addition to technical work; it is the set of obligations that makes technical work trustworthy. The codes examined here differ in structure and legal force, but they agree that public safety comes first, that engineers work within their competence, that engineering statements must be truthful and complete, and that conflicts of interest must be disclosed.

The case studies show those obligations failing in characteristic ways. In the Therac-25 accidents, as Leveson and Turner documented, reports of harm were explained away and software became a single point of failure. In the Volkswagen case, EPA described software designed to recognize an emissions test. In the 737 MAX, the House committee found a nose-down command that relied on one sensor, faulty assumptions about pilot response, and information withheld from the FAA and pilots. Each turned on technical decisions of the kind engineers make every day.

The habits that follow are modest but demanding. State facts, assumptions, and uncertainty separately. Keep the evidence. Disclose conflicts early. Respect other people's intellectual property. Raise safety concerns in writing, and escalate them when they are ignored. Learn the legal protections, and their limits, where you work. Treat each software safety function as a system problem. And because codes change, read the owner's current text before relying on a specific provision.