Intro. To Aerospace Eng. Design: - Ethics in Design - System Engineering

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 72

Intro.

To Aerospace
Eng. Design

• Ethics in design
• System Engineering
Outline

• Why be an ethical engineer


• Ethics and morals
• Ethical thinking
• Historical examples
• Case studies

2
Engineering ethics

• Ethics is a fundamental and required component of any


profession that affects society and individuals.
• Engineering ethics is the study of moral issues and decisions
confronting those involved in engineering, and the study of
related questions about moral conduct, character, ideals, and
relationships of people and organizations involved in
technological development.

3
Engineering ethics (Cont.)

• Applying ethics in engineering is not only about the right thing


in a reactive way, but also about being proactive in preventing
possible future problems.
• In engineering design, we must consider the way our design
will be used and its impact on society and our environment.
• Often we will need to make moral decisions between equally
valid competing choices.

4
Ethics in engineering?

Why should you care about ethics as a future engineer


• Society expects you as an individual to be a good person.
• To be licensed requires you to pass an engineering ethics
exam.
• Legal obligation to practice as a professional, licensed
engineering.
• Implied social contract of profession.

5
Ethics and morals

• When considering ethical issues, sometimes a distinction is


made between morals and ethics. Morals refer to generally
accepted standards of right and wrong in society (Do morals
vary among societies on Earth?)
• Ethics refers to more abstract principles which may be
codified in professional rules or regulations.

6
Ethics and morals

• Moral philosophy or theory refers to moral principles that we


would term as ethics, so you may choose to view them as
being interchangeable in application.
• Regardless, both morals and ethics establish the standards of
right conduct, regardless of whether they are implied by
society or written down in the form of professional
regulations.

7
Ethics and laws

• Note that you should consider ethical and moral statements


separately from law. An act that is legal may not necessarily be
ethical. For example, your company may be legally allowed to
release pollutant into the environment, but if it causes serious
health concerns is it ethical? i.e. legally permissible does not
imply morally permissible.

8
Ethics and laws (Cont.)

• Conversely, illegality does not necessarily imply immorality.


• Government regulations may not allow your company to
release any amount of chemical X into the environment, but
shuttering your company to avoid breaking the law may result
in economic losses for the community.
• If chemical X causes irritation but not death, this would be a
moral dilemma. (what if legal requirements are too strict or
unjust?)

9
Farming ethical thinking

• We can make ethical problems easier to understand by casting


the issue into one of the following three forms of statements:
• Factual: a statement that can only be true or false.
• Conceptual: a statement dependent on the meaning of scope of
certain terms.
• Moral: a statement that something is either right or wrong.

10
Factual issues

• Consider a disagreement between two engineers about whether


or not a product is unsafe. There is no doubt that the two
engineers agree that unsafe products should not be sold;
however, they may disagree as to whether or not the product
will cause accidents in use.

11
Factual issues (Cont.)

• In this case, there is an issue related to the facts (the product is


wither safe or unsafe) that can be resolved with more
information (e.g. testing the product).
• This moral issue has to do with the truth or falsehood of a
factual statement.

12
Conceptual issues

• Moral issues may be the result of uncertainty regarding the


scope or meaning of a term.
• For example, chemical X if released into the environment,
may be considered harmful, but what do we mean by
“harmful”?

13
Conceptual issues (Cont.)

• Consider if chemical X was a byproduct of a process you


designed. If chemical X caused death in all exposed, then it
would be unethical to release it into the environment, even if it
was not regulated by law.
• If chemical X only caused an irritation in a small percentage
of the population, would it be acceptable? Conceptual issues
may require the establishment of terms, and coming to an
agreement in how they will be applied.

14
Moral issues

• Moral issues involve questions that have to do with the


relevance and application of one or more moral principles.
Keep in mind that moral principles are based upon societal
norms of right and wrong.

15
Moral issues (Cont.)

• For example, knowingly producing large quantities of


chemical X which is a known carcinogen would violate the
general prohibition of harming others.
• Removing chemical X at significant cost if it is only a mild
irritant for some, may not violate a general moral principle.

16
Moral problems

• While factual and conceptual issues can be resolved by further


inspection and agreement, resolving moral issues can be
difficult.
• In applying moral principles we should distinguish relevance
problems from conflict problems.

17
Moral problems (Cont.)

• Relevance problems occur when we are not certain if a moral


principle applies in this situation. Often, a relevance problem
is related to a conceptual issue and may be resolved in
conjunction with an establishment of terms or scope.

18
Moral problems (Cont.)

• Conflict problems occur when we are faced with the


application of two or more moral principles which appear to
apply, but require different or conflicting actions to resolve.
• Determining an ethical resolution in this case is not about
determining good vs bad, but choosing between two good but
competing options.

19
Resolving problems

• Resolving relevance problems usually requires making unclear


concepts clear, and applying logic to make a decision.
• Conflict problems are often difficult to resolve and require a
different approach.

20
Resolving problems (Cont.)

Conflict problems can be resolved using the following methods:


• Find a middle ground: it may be possible to satisfy both moral
requirements in a modified form.
• Use low-level considerations: it may be helpful to bring into
consideration other factors that at first were considered to not
be relevant. This may tip the scale towards once choice over
another.
• Make the hard choice: when no reconciliation of options is
possible, you may be forced to make the hard choice.

21
Moral theories

• Moral conduct (how we make moral decisions) is based upon


concern for others, not oneself, law or other.
• To make such a decision, we must be able to discern from
wrong.

22
Moral theories (Cont.)

How do we define what is morally right? This is no clear


consensus about the answer; however, there are four main moral
theories that can be applied:

Utilitarianism: the morally right choice is the one that provides


the greatest benefit to the most people.
Duty ethics: the action which we are duty bound to perform is
the right choice, regardless of the actual outcome.

23
Moral theories (Cont.)

Rights ethics: Actions are wrong if they violate the moral rights
of the individual.
Virtue ethics: Actions that are wrong are those that manifest bad
characteristics (vices) as opposed to those that manifest good
characteristics (virtues).

24
Social contract

Engineers may be obligated in a number of ways:


• Loyalty to an employer or client.
• A legal contract with a client or employer
• A professional code of conduct enforced by a licensing body
Regardless of the legal or professional requirements, there is an
underlying implied social contract.
An engineer’s primary responsibility is to safeguard the well
being of the public!

25
Historical examples

• There are many examples from history of ethical and moral


issues that have shaped the engineering profession. Engineers
in most counties, are regulated as a profession and subject to
an ethical code of conduct.
• In Canada and the US, the engineer professions are self-
regulated by licensing organizations, which are themselves
created through legislation.

26
Historical examples (Cont.)

• These governing bodies were created in direct response to


historical events resulting in loss of life and property due to
engineering negligence.
• For example, in Canada, the Quebec Bridge collapse (1907)
and in the US, the Boston Molasse disaster (1919) created
public pressure to regulate the practice of engineering.

27
Sample questions

You should design things as if you had to use them everyday.


• True.
• False.

28
Sample questions (Cont.)

You see a design that violates common safety practices.


• You should go as high up the chain of responsibility as
necessary to fix the problem.
• It is not your problem, so you should ignore it.

29
Sample questions (Cont.)

Reverse engineering a competitor’s product is unethical.


• True
• False

30
Sample questions (Cont.)

Using the results of reverse engineering can get you in trouble if


you learn from a competitor’s design and copy, but you do not
realize they have a patent
• True
• False

31
Scenario I

• XYZ orders 5000 custom made parts from ABC for one of its
products. When the order is originally made ABC indicates it
will charge $75 per part.
• This cost is based on part on the cost of materials. After the
agreement is completed, but before production of the part
begins, ABC engineer Christine Carsten determines that a muc
less expensive metal alloy can be used while only slightly
compromising the integrity of the part.
• Using the less expensive alloy would cut ABC’s costs by $18 a
part.

32
Scenario I (Cont.)

• Christine brings this to the attention of ABC’s Vernon Waller, who


authorized the sales agreement with XYZ.
• Vernon asks, “how would anyone know the difference?” Christine
replies, “probably no one would unless they were looking for a
difference and did a fair amount of testing. In most cases, the
performance will be virtually the same-although some parts might
not last quite as long”. Vernon says, “great, Christine, you’ve made
a bundle for ABC”. Puzzled, Christine replies, “but shouldn’t you
tell XYZ about the change?” “why?” Vernon asks, “ the basic idea is
to satisfy the customer with good quality parts, and you’ve said we
will. So, what’s the problem?"

33
• The problem, Christine thinks to herself, is that the customer
isn’t getting what was promised. Further, even if XYZ would
be satisfied with the different part, shouldn’t it be given the
opportunity to decide if it finds the change acceptable – and to
benefit from lowered cost?
• Should Christine shear her further thoughts with Vernon, or
should she simply drop the matter?

34
Scenario II

• Christine shears her further thoughts with Vernon. He replies,


“I just don’t agree, Christine. This is business, not engineering.
XYZ will be a satisfied customer and we will be a satisfied
supplier. We are not in the business of giving away money, you
know”.
• Is there any reason for Christine to press further?
• Do you agree that Vernon is just doing “good business”?

35
Scenario III

• Christine decides there is nothing further for her to do. The


less expensive part is produced. As the shipment is prepared to
be sent to XYZ, Christine is asked to sign a report verifying
that the specifications for the part have been met. As she looks
over the details she notices that the original composition of the
metal is listed rather than the cheaper alloy. Should she sign
the report anyway?

36
Scenario IV

• Christine refuses to sign the report. However, Vernon


persuades her fellow engineer, John Richards, to sign it.
• What should Christine do now?

37
DC-10 crash

• In 1974, the first crash of a fully loaded DC-10 occurred over


Paris, killing 346 people. The crash occurred due to defective
design; a design flaw that was known in advance.

38
DC-10 crash (Cont.)

• In 1974, the first crash of a fully loaded DC-10 occurred over


Paris, killing 346 people. The crash occurred due to defective
design; a design flaw that was known in advance.
• The fuselage was developed by Convair, a subcontractor to
McDonnell-Douglas (MD). In 1972, a senior engineer
(Applegate) wrote a memo detailing the dangers of the design
that could allow cargo doors to open in flight, resulting in
decompression and collapse of the floor of the passenger
cabon. Applegate recommended a redesign to fix the problem.

39
DC-10 crash (Cont.)

• In response, management did not dispute the analysis, but


considered the financial liabilities of admitting the problem to
MD. The redesign would result in the grounding of all DC-10
and out MD at a significant disadvantage.

40
DC-10 crash (Cont.)

• In response, management did not dispute the analysis, but


considered the financial liabilities of admitting the problem to
MD. The redesign would result in the grounding of all DC-10
and out MD at a significant disadvantage.
• What is the moral dilemma faced by Applegate? What is his
obligation to his employer? To McDonnell-Douglas? To
public?

41
Shuttle challenger accident

• On Jan. 28, 1986, seven astronauts were killed when the space
shuttle they were piloting, the Challenger, exploded just over a
minute into flight. The failure of the solid rocket booster O-
rings to seat properly allowed hot combustion gases to leak
from the side of the booster and burn through the external fuel
tank. The failure of the O-ring was attributed to several
factors, including faulty design of the solid rocket booster,
insufficient low temperature testing of the O-ring material and
the joints that the O-ring sealed, and lack of communication
between different levels of NASA management.s

42
Shuttle challenger accident (Cont.)

43
Design issues

• The SRB were designed is segments, pinned together using a


tang and clevis. During launch, the pressure of combustion
gases would press the putty on the inside of the joint to
compress air between the putty and O-rings. Pressure acting
on the annular segments would cause the tang and clevis to
rotate relative to one another, opening the joint, and unloading
the O-rings.

44
Design issues (Cont.)

• Morton-Thiokol noted the design problem in earlier testing


(1977) and had made the following design changes:
1. Tolerances on the joints were tightened.
2. O-ring diameter was increased, O-ring tolerances were
tightened.
3. Shims were introduced to further tighten the joint.

45
Design issues (Cont.)

• Erosion of the O-ring was noted after the second shuttle flight.
The rings maintained a seal but there was a concern that they
may not perform as designed. Different types of putty were
tested for performance.

46
Design issues (Cont.)

• Erosion of the O-ring was noted after the second shuttle flight.
The rings maintained a seal but there was a concern that they
may not perform as designed. Different types of putty were
tested for performance.
• For STS-51C (Nov. 981), there was evidence of gas blow-by
on the recovered SRB. This shuttle launch happened to
coincide with coldest launch temperature to date. Morton-
Thiokol began testing the performance of the O-rings at lower
temperatures, and in 1985 ordered new steel billets for
redesigned SRB.

47
Design issues (Cont.)

• The night before the launch of STS-51L (Jan 1986) was the
coldest on record, with a predicted O-ring temperature of 29°F.
Thiokol’s engineers were concerned about the performance of
the O-rings, and recommended postponing launch until an O-
ring temp of 54°F could be reached. Shuttle design
requirements specified a lower operating temperature of 31°F.

48
Design issues (Cont.)

• The actual night-time temperature dropped as low as 8°F. the


coldest joint on the SRB was estimated to be 28±5°F. At
launch, the O-rings were too cold to seat properly allowing hot
combustion gases to pass by both sets of rings. Initially
propellant oxides temporarily sealed the joint; however, a
strong wind shear during ascent broke the seal allowing
5000°F combustion gases to burn through the external
propellant tank.

49
Design issues (Cont.)

• Prior to launch, the shuttle program had suffered a number of


embarrassing delays. There was significant political pressure
on NASA to demonstrate that the system was operational and
could be profitable in the future. The shuttle was designed,
built, and operated by engineers and employees of
subcontracted companies and NASA centers from across the
US.

50
Design issues (Cont.)

• At several points, Morton-Thiokol engineers voiced concerns


that the launch should not proceed for safety reasons during a
teleconference. At Cape Kennedy, a Morton-Thiokol engineer
refused to sign-off on the recommendation to launch.
Management at Morton-Thiokol discounted the advice of their
engineers, considering their evidence to be insufficient, and
ultimately approved the recommendation to launch.

51
• A commissioned report identified several issues that
contributed to the loss of STS-51L
1. A wide difference in opinion as to the probability of failure
with a loss of vehicle existed between engineering and
management. Prior successful launches were seen as
evidences of reduced risk.
Was the risk reduced? Did the engineers do enough to push their
concerns?

52
Case study

• NASA had demonstrated a history of being unwilling to wat


out risky weather. What is the responsibility of engineers in
evaluating safety risks?
• The design was sensitive to low ambient temperatures and
assembly tolerances. The field joint did not perform as
intended. More importantly, the engineers responsible for the
design were aware of the problem and were redesigning the
joint. Are the engineers to blame? Was management to blame?

53
Case study

Consider the following issues and questions:


• The shuttle design did not include an escape mechanism for
the crew. Once the SRB are ignited, there is no fail-safe.
Under what conditions would you say it is safe to launch?
• One recommendation was the establishment of an independent
organization reporting directly to NASA administration. How
would an anonymous reporting scheme for NASA and
contractor employees help safety.

54
Case study (Cont.)

• Several Morton-Thiokol engineers identified potential


problems months in advance, communicating their concerns to
management. In the end, they consented to management
decision regarding launch. What else could they have done in
the months prior to the accident?

55
Intro. To Aerospace
Eng. Design

• Systems Engineering
Outline

• What is systems engineering


• What is a system
• Systems engineering as design
• What does a systems engineer do?
• Further reading

57
What is systems engineering

• System engineering is the art and science of developing an


operable system capable of meeting requirements within
imposed constraints. The definition is somewhat independent
of scale, and so these words are useful only if one understand
that is the big-picture view which ta taken here. We are talking
here about developing an airplane, a spacecraft, a power plant,
a computer network. We are not talking about designed a beam
to carry a particular load across a known span.
Michael D. Griffn, Administrator, NASA, 2007

58
What is a system?

• A system is a construct or collection of different elements that


together produce results not obtainable by the elements alone. The
elements, or parts, can include people, hardware software, facilities,
policies, and documents; that is, all things required to produce
system-level results. The results include system level qualities,
properties, characteristics, functions, behavior, and performance.
The value added by the system as a whole, beyond that contributed
independently by the parts, is primary created by the relationship
among the parts; that is, how they are interconnected.
Eberhardt Rechtin, “Systems Architecting of Organizations: why
eagles can’t swim, 2000.

59
What is a system

60
Systems engineering as design

• Systems engineering (SE) can be viewed as design at a higher


level than we have discussed to date. It is a logical way of
thinking about the bigger picture of design.

61
Systems engineering as design (Cont.)

• Systems engineering (SE) can be viewed as design at a higher


level than we have discussed to date. It is a logical way of
thinking about the bigger picture of design.
• The design of systems requires an initial effort to formally
define the problem before attempting to solve it. A key part of
this definition is the establishment and communication of
measurable system requirements.

62
Systems engineering as design (Cont.)

• SE focused on the entire life cycle of the system: from the


initial development and planning of the system, through the
implementation and maintenance of the system, and through
the final decommissioning of the system. The determination of
project costs are planned for the entire system life cycle.
Systems are tested for satisfaction of the system requirements,
and most importantly, all aspects of the system are thoroughly
documented.

63
Systems engineering as design (Cont.)

• Systems engineering is inherently multi-disiciplinary in


nature. As systems engineering is responsible for developing
the product and the process for producing it, models of both
the physical components and the processes of the system are
required.

64
Systems engineering as design (Cont.)

• Systems engineering is inherently multi-disiciplinary in


nature. As systems engineering is responsible for developing
the product and the process for producing it, models of both
the physical components and the processes of the system are
required.
• Similar to the functional analysis we discussed earlier in the
course, systems engineering often models a system as a set of
interconnected sub-systems. The flow of information between
sub-systems us modeled along with the behavior of the sub-
systems themselves.

65
Systems engineering as design (Cont.)

• The process of modeling systems begins with reductionism;


breaking down a complex problem into smaller, easier to solve
components (i.e. divide and conquer)

66
Systems engineering as design (Cont.)

• The process of modeling systems begins with reductionism;


breaking down a complex problem into smaller, easier to solve
components (i.e. divide and conquer).
• Complex projects are made manageable by decomposing both
the product and the development process into progressively
smaller pieces. The product, i.e. the system, can be
decomposed into a hierarchy of sub-systems. The process can
be decomposed into a hierarchy of sub-processes.

67
Systems engineering as design (Cont.)

• The integration of sub-systems, often developed by multiple


risk-sharing partners, requires the development of clearly
interface requirements. As the system is built from a number
of interconnected sub-systems, systems engineering requires
coordination with project management to ensure that sub-
systems are implemented in the correct order, and that sub-
systems provide the correct output to be used as input to other
sub-systems.

68
What dies a systems engineer do?

A systems engineer’s product is documentation! This make take


the form of
• A mission statement
• A requirements document including verification and validation
• A description of functions and objects
• Figures of merit
• A test plan
• A drawing of system boundaries
• An interface control document
• A listing of deliverables

69
What dies a systems engineer do?

A systems engineer’s product is documentation! This make take


the form of
• System models
• A sensitivity analysis
• A trade-off study
• A risk analysis
• A life cycle analysis
• A description of the physical architecture

INCOSE, www.incose.org

70
What does a systems engineer do?

• In summary, the systems engineer is skilled in the art and


science of balancing organizational and technical interactions
in complex systems. However, since the entire team is
involved in the systems engineering approach, in some ways
everyone is a systems engineer. Systems engineering is about
tradeoffs and compromises, about generalists rather than
specialist. Systems engineering is about looking at the “big
picture” and not only ensuring that they get the design right
(meet requirements) but that they get the right design.
NASA systems engineering handbook, 2007.

71
Further reading

• International Council on Systems Engineering,


www.incose.org
• Space Systems Engineering, spacese.spacegrant.org
• NASA Systems Engineering Handbook, NASA/SP-20047-
6015.

72

You might also like