CS代考 SWEN90010 - High Integrity

SWEN90010 – High Integrity
Systems Engineering Safety Engineering, HAZOP, Fault Tree Analysis
Toby MD 8.17 (Level 8, Doug McDonell Bldg)
http://people.eng.unimelb.edu.au/tobym @tobycmurray

SAFETY ENGINEERING

Copyright University of Melbourne 2016, provided under Creative Commons Attribution License
In light of the above, a more precise definition:
software and hardware used under correct operating conditions don¡¯t cause unacceptable harm to people or environment.

Safety Engineering Process
4 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Safety Engineering
How do we engineer safe systems?
5 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Copyright University of Melbourne 2016, provided under Creative Commons Attribution License
Safety Engineering
How do we engineer safe systems?
Safety engineers are experts in their domain:
medical, rail signalling, aviation etc. Safety engineers are experts in past accidents,
incidents and failures.

6 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Safety engineers examine past accidents etc.
looking for hazards:
things that could lead to (future) accidents
6 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Copyright University of Melbourne 2016, provided under Creative Commons Attribution License
Safety engineers examine past accidents etc.
looking for hazards:
things that could lead to (future) accidents
Then design the system to be safe in the face of these things, reducing the chance of accidents happening.

Safety engineers examine past accidents etc.
looking for hazards:
things that could lead to (future) accidents
Then design the system to be safe in the face of these things, reducing the chance of accidents happening.
Tends to be the same factors over and over again. Doing it properly requires determining causation.
Not enough to know that the accident occurred because
a device failed; need to understand why it failed, what caused
it to fail and e.g. why the pilot didn¡¯t notice. 6 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Often contested, not always clear cut.
Not correlation.
7 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Often contested, not always clear cut.
Not correlation.
Determined by counterfactual reasoning.
7 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Copyright University of Melbourne 2016, provided under Creative Commons Attribution License
Often contested, not always clear cut.
Not correlation.
Determined by counterfactual reasoning.
A counterfactual: ¡°if A hadn¡¯t happened, what would be the case …¡±

Causality is not Correlation
8 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Causality is not Correlation
Absence of causation is revealed by counterfactual reasoning.
8 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Causality is Not Correlation
Confounding: deaths by drowning correlated with ice-cream consumption
9 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Causality is Not Correlation
Confounding: deaths by drowning correlated with ice-cream consumption
(common cause: warm weather)
9 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Copyright University of Melbourne 2016, provided under Creative Commons Attribution License
Causality is Not Correlation
Confounding: deaths by drowning correlated with ice-cream consumption
(common cause: warm weather)
Reversed Causality: barometer reading always drops before a storm

Past Causes as Hazards
Safety engineers study past accident causes to determine hazards for new systems
Works because new systems tend to be similar to old ones.
e.g. entirely new modes of transport tend to be invented rarely.
But must be done systematically
by following a process, to ensure repeatability.
(This is true of all engineering activities, of course.)
10 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Safety Engineering Tasks
Preliminary Hazard Analysis
Implementation
11 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Safety Engineering Tasks
Preliminary Hazard Analysis
Based on requirements and early design: ¡°what could go wrong?¡±
Implementation
11 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Safety Engineering Tasks
Preliminary Hazard Analysis
Based on requirements and early design: ¡°what could go wrong?¡±
Hazard brainstorming.
Implementation
11 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Safety Engineering Tasks
Preliminary Hazard Analysis
Based on requirements and early design: ¡°what could go wrong?¡±
Hazard brainstorming.
Given those hazards, design the system to eliminate or mitigate them (depending on their risk)
Implementation
11 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License
e.g. HAZOP

Safety Engineering Tasks
Preliminary Hazard Analysis
Based on requirements and early design: ¡°what could go wrong?¡±
Hazard brainstorming.
Given those hazards, design the system to eliminate or mitigate them (depending on their risk)
Implementation
Was it done right?
11 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License
e.g. HAZOP
e.g. Fault-Tree Analysis
e.g. Formal Specification

Safety Engineering Tasks
Preliminary Hazard Analysis
Based on requirements and early design: ¡°what could go wrong?¡±
Hazard brainstorming.
Given those hazards, design the system to eliminate or mitigate them (depending on their risk)
Implementation
Was it done right?
11 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License
e.g. HAZOP
e.g. Fault-Tree Analysis
e.g. Formal Specification
e.g. Program Verification

HAZOP: HAZARDS AND OPERABILITY STUDY

Copyright University of Melbourne 2016, provided under Creative Commons Attribution License
HAZOP Study
A method for Preliminary Hazard Analysis
Exploratory analysis, systematically brainstorming what could go wrong
Introduced originally to understand hazards in chemical processes, 1950s
Adopted in safety-critical software engineering due to its effectiveness

HAZOP Overview
Input: high-level system description as
a collection of design items
14 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

HAZOP Overview
Input: high-level system description as
a collection of design items Design item: an intended behaviour, e.g.
an event in a process or a state transition
14 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

HAZOP Overview
Input: high-level system description as
a collection of design items Design item: an intended behaviour, e.g.
an event in a process or a state transition
¡°when sensor X is triggered, valve B is closed immediately¡±
14 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

HAZOP Overview
Input: high-level system description as
a collection of design items Design item: an intended behaviour, e.g.
an event in a process or a state transition
¡°when sensor X is triggered, valve B is closed immediately¡±
Each design item is systematically mutated to analyse what could happen when the intended behaviour doesn¡¯t occur, and to determine the risk (consequences and frequency).
14 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Assessing Hazard Risks
IEC – 61508
Safety engineering about moving from Class I towards IV 15 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Risk: Consequence x Freq.
16 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Example Scenario
17 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Example Scenario Brake Pedal
17 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Example Scenario
Brake Pedal
Brake Controller ECU
17 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Example Scenario
Brake Pedal Brake Controller Brake ECU
17 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Design Items
Depends on level of abstraction.
18 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Design Items
Depends on level of abstraction.
¡°when detecting a rapid increase in brake pedal pressure, the ECU will
apply the brake with full force
to implement emergency braking.¡±
18 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License
¡°the Brake Controller control loop is scheduled to run once every 1/10th of a second¡±

Design Items
Depends on level of abstraction.
¡°when detecting a rapid increase in brake pedal pressure, the ECU will
apply the brake with full force
to implement emergency braking.¡±
¡°the Brake Controller control loop is scheduled to run once every 1/10th of a second¡±
18 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Design Items
Depends on level of abstraction.
¡°when detecting a rapid increase in brake pedal pressure, the ECU will
apply the brake with full force
to implement emergency braking.¡±
¡°the Brake Controller control loop is scheduled to run once every 1/10th of a second¡±
¡°the brake controller ECU receives a signal from the brake pedal when its foot pressure changes¡±
18 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

What-Ifs to Consider
19 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

What-Ifs to Consider
Design Item
¡°the brake controller ECU receives a signal from the brake pedal when its foot pressure changes¡±
19 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

What-Ifs to Consider
Design Item
¡°the brake controller ECU receives a signal from the brake pedal when its foot pressure changes¡±
What if there is no signal from the brake pedal? What if the signal comes early?
What if the signal comes late?
19 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

What-Ifs to Consider
Design Item
¡°the brake controller ECU receives a signal from the brake pedal when its foot pressure changes¡±
What if there is no signal from the brake pedal? What if the signal comes early?
What if the signal comes late?
For each, think about the potential hazards that could arise and rate their consequences (catastrophic, critical, marginal, negligible).
19 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Hazards and Consequences
20 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Hazards and Consequences
What if there is no signal from the brake pedal?
20 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Hazards and Consequences
What if there is no signal from the brake pedal?
What if the signal comes early?
20 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Hazards and Consequences
What if there is no signal from the brake pedal?
What if the signal comes early?
What if the signal comes late?
20 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Hazards and Consequences
What if there is no signal from the brake pedal? 1. car fails to stop. Consequence: Catastrophic
2. car gets stuck. Consequence: Critical (?) What if the signal comes early?
What if the signal comes late?
20 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Hazards and Consequences
What if there is no signal from the brake pedal? 1. car fails to stop. Consequence: Catastrophic
2. car gets stuck. Consequence: Critical (?)
What if the signal comes early? 1. nonsensical, not applicable (?)
2. car brakes too quickly (?) What if the signal comes late?
20 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Hazards and Consequences
What if there is no signal from the brake pedal? 1. car fails to stop. Consequence: Catastrophic
2. car gets stuck. Consequence: Critical (?)
What if the signal comes early? 1. nonsensical, not applicable (?)
2. car brakes too quickly (?)
What if the signal comes late?
1. car fails to stop in time. Consequence: Catastrophic 2. car fails to start in time. Consequence: Critical (?)
20 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

HAZOP Guidewords
Used to explore What-Ifs systematically
21 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

HAZOP Process
22 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

HAZOP Process for each design item
22 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

HAZOP Process for each design item
for each guideword
22 Copyright University of Melbourne 2016, provided under Creative Commons Attribution License

Copyright University of Melbourne 2016, provided under Creative Commons Attribution License
HAZOP Process
for each design item
for each guideword
interpret the guideword against the design item (ask ¡°what could i

程序代写 CS代考加微信: powcoder QQ: 1823890830 Email: powcoder@163.com

Related Posts