Chapter 10 — Engineering ethics and safety
Lesson map
Lesson 10 published. Map, example, EX028.
flowchart TD
N0["Learning outcomes"]
N1["10.1 Duties of an engineer"]
N2["10.2 Safety in transit systems"]
N3["10.3 Schedule versus safety"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX028"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["10.1 Duties of an engineer"]
N2["10.2 Safety in transit systems"]
N3["10.3 Schedule versus safety"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX028"]
[Learning outcomes]
|
v
[10.1 Duties of an engineer]
|
v
[10.2 Safety in transit systems]
|
v
[10.3 Schedule versus safety]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX028]
Learning outcomes
You will (1) apply engineering codes of ethics to security decisions; (2) recognise public-safety dimensions of transit systems; (3) handle conflicts between schedules and safety.
10.1 Duties of an engineer
Professional engineering codes generally place public safety, health and welfare above employer or client interests, and require honesty about limits of competence. Daniel asks Sofia to read her national engineering body's code and to apply it to security work. Hiding a known weakness to meet a launch date conflicts with the duty of honesty. Claiming expertise in an area she has not studied conflicts with competence limits. Security engineers face these dilemmas regularly, and ethics provides a framework for deciding before pressure arrives, rather than improvising when a manager asks for silence.
10.2 Safety in transit systems
Transit systems carry people, so security failures can become safety failures. If an attacker disrupts passenger information screens during an emergency, people may go to the wrong platform. If fare gates fail closed during an evacuation, they could trap passengers. Sofia learns that fail-safe defaults from Saltzer and Schroeder (1975) must be interpreted with care: for access to data, deny by default; for physical gates during fire alarms, open by default. Security architecture in transit must be coordinated with safety engineers, who often have regulatory duties and their own analysis methods.
10.3 Schedule versus safety
During Sofia's placement, a contractor wants to switch on a new passenger app feature before its security review is complete, because of a press launch. Sofia, as a student, cannot approve or block it, but she can raise her concern in writing to Daniel with the specific risk: the feature exposes journey histories through an unauthenticated interface in the test build. Daniel escalates, and the feature launches a week later after a fix. The lesson is that ethics often means making a risk visible to the right person in writing, clearly and promptly.
Worked example
Sofia maps her engineering code to three security dilemmas, distinguishes data and physical fail-safe defaults and writes a concise risk note that delays an unsafe launch.
Synthetic case. The launch, contractor and app feature are synthetic; Saltzer and Schroeder (1975) is real.
Errors and limits
Codes of ethics vary by country and body. Raising a concern does not guarantee action; escalation paths must exist.
Exercises
- EX028 — Paramount duty. What do engineering codes place above employer interests? Rubric: 3 = public safety, health and welfare;; 2 = safety;; 1 = profit;; 0 = none.
- EX029 — Gate default. During a fire alarm, should fare gates fail open or closed, and why? Rubric: 3 = open, so passengers can evacuate; safety overrides fare protection;; 2 = open;; 1 = closed;; 0 = none.
- EX030 — Student action. What could Sofia do about the premature launch? Rubric: 3 = raise the specific risk in writing to Daniel for escalation;; 2 = written concern;; 1 = vague;; 0 = none.
Synthesis
Ethical engineering puts public safety first, adapts defaults to safety context and makes risks visible in writing.
Continue studying — chapter 10 of 50
← Chapter 09 (draft) · Course chapter index · Chapter 11 (draft) →