Event Tree Analysis (ETA) is an inductive method used to evaluate the consequences of an

initiating event, such as a fault, by systematically mapping out possible outcomes based on
decisions or system responses. It is particularly useful in assessing countermeasures to
functional problems through a "what-if" approach. Below is an explanation of ETA, using the
provided example of a stuck accelerator, and an extension to Cause Consequence Analysis
(CCA).

Event Tree Analysis (ETA)

ETA starts with an initiating event and branches out into possible outcomes based on the
success or failure of subsequent events or decisions. Each branch represents a decision point
or system response, and the tree traces all possible paths to their outcomes. The method is
qualitative but can incorporate probabilities for quantitative analysis.

Example: Stuck Accelerator

The initiating event is a stuck accelerator in a vehicle. From this point, the driver’s actions
and system responses determine the outcome. The decision points and outcomes are as
follows:

1. Driver’s Response:
o Push Clutch: Disconnects the engine from the wheels, allowing the engine to
run at high speed but rendering the situation non-dangerous (safe outcome).
o Push Brake: Attempts to stop the vehicle. This has two sub-outcomes:
 Engine Stalls: The vehicle stops, resulting in a harmless situation.
 Engine Does Not Stall: The driver must maintain braking, which is
challenging over time. If the brakes are near failure, the stress could
cause a brake failure, leading to a difficult-to-control situation.
o Push Both Clutch and Brake: This is not shown in the figure but would
likely result in a non-critical situation, as the clutch disengages the engine, and
the brake slows the vehicle.
o Do Nothing: Leads to inevitable damage, as the vehicle continues to
accelerate uncontrollably.
2. System Response:
o Modern engine Electronic Control Units (ECUs) include a safety function
that detects an implausible combination of accelerator and brake inputs (e.g.,
both pressed simultaneously). If detected, the ECU limits engine torque,
mitigating the risk of a dangerous outcome.

Qualitative and Quantitative ETA

 Qualitative ETA: The example provided is qualitative, focusing on identifying

possible outcomes and their nature (e.g., safe, hazardous, or critical). This is sufficient
for many practical applications, such as designing countermeasures.
 Quantitative ETA: Probabilities can be assigned to each branch to calculate the
likelihood of specific outcomes. For instance:
o The probability of an outcome is computed by multiplying the probabilities of
"yes" and "no" decisions along a path from the initiating event to the outcome.
 o If multiple paths lead to the same outcome, their probabilities are summed.
o In the example, the probability of the engine running at high speed is given by:
P(Engine running at high speed)=P(Y1)P(Y2)P(N4)+P(N1)P(Y2)P(\
text{Engine running at high speed}) = P(Y_1)P(Y_2)P(N_4) +
P(N_1)P(Y_2)P(Engine running at high speed)=P(Y1)P(Y2)P(N4)+P(N1
)P(Y2) where P(Yi)P(Y_i)P(Yi) and P(Ni)P(N_i)P(Ni) represent the
probabilities of "yes" and "no" decisions at each decision point.

Figure 3.3 (Conceptual Explanation)

Figure 3.3 likely depicts a tree diagram starting with the stuck accelerator as the initiating
event. The branches represent the driver’s actions (clutch, brake, both, or nothing) and system
responses (e.g., ECU torque limitation). Each path ends in an outcome, such as:

 Safe (e.g., engine stalled or clutch disengaged).

 Hazardous but manageable (e.g., engine running at high speed but not dangerous).
 Critical (e.g., brake failure or uncontrolled acceleration).

Cause Consequence Analysis (CCA)

CCA extends ETA by incorporating Fault Tree Analysis (FTA) at each decision point
(bifurcation) in the event tree. While ETA focuses on what happens after an initiating event,
CCA also examines why a specific decision or system response occurs by analyzing the
underlying causes of each branch.

How CCA Extends ETA

 In ETA, each decision point (e.g., "Does the driver push the brake?") is a binary
choice (yes/no) leading to further branches.
 In CCA, a fault tree is attached to each decision point to analyze the reasons behind
the system’s or operator’s behavior. For example:
o At the decision point "Does the brake stall the engine?" a fault tree could
explore causes like:
 Brake system condition (e.g., worn brake pads).
 Engine control logic (e.g., ECU failure to detect accelerator-brake
conflict).
 Driver behavior (e.g., insufficient brake pressure).
o This fault tree identifies root causes that lead to a "yes" or "no" outcome at
that decision point.

Example in Figure 3.4

Figure 3.4 likely shows a portion of the ETA from Figure 3.3 with a fault tree attached to one
decision point. For instance:

 Decision Point: "Does the brake stall the engine?"

o ETA Branch: If the engine stalls, the outcome is safe; if not, the situation
becomes harder to control.
 o CCA Extension: A fault tree is hooked to this decision point to analyze why
the engine might not stall. The fault tree could include:
 Top Event: Engine does not stall.
 Causes:
 Brake system failure (e.g., insufficient braking force).
 ECU failure to limit torque.
 Mechanical issue in the engine (e.g., high torque output
preventing stall).
 Each cause is further broken down into basic events (e.g., sensor
failure, software glitch, or mechanical wear).

This fault tree provides a deeper understanding of why a particular outcome occurs, enabling
engineers to design targeted countermeasures (e.g., improving ECU logic or brake system
reliability).

Key Differences Between ETA and CCA

1. Scope:
oETA focuses on mapping outcomes from an initiating event.
oCCA combines ETA with FTA to analyze both outcomes and their causes.
2. Purpose:
o ETA is used to evaluate the consequences of faults and assess
countermeasures.
o CCA provides a more comprehensive analysis by identifying why specific
decisions or system responses occur, aiding in root cause analysis.
3. Complexity:
o ETA is simpler, focusing on a forward-looking "what-if" approach.
o CCA is more complex, as it requires constructing fault trees for each decision
point.

Applications in Electric Vehicles

In the context of electric vehicles (EVs), ETA and CCA are critical for ensuring functional
safety (as per standards like ISO 26262). For example:

 Initiating Event: Failure of the electric motor controller.

 ETA: Maps outcomes based on driver actions (e.g., applying regenerative braking)
and system responses (e.g., battery management system intervention).
 CCA: Analyzes why the motor controller failed (e.g., software bug, overheating, or
sensor failure) by attaching fault trees to each decision point.

This dual approach helps engineers design robust safety mechanisms, such as redundant
systems or fail-safe modes, to mitigate risks in EVs.
Summary

 ETA: A qualitative or quantitative method to trace the consequences of an initiating

event (e.g., stuck accelerator) through decision points (e.g., driver actions, ECU
response) to outcomes (e.g., safe or hazardous).
 CCA: Extends ETA by adding fault trees at decision points to analyze the causes of
specific system or operator behaviors.
 Example Application: For a stuck accelerator, ETA identifies outcomes like engine
stalling or brake failure, while CCA investigates why the engine didn’t stall (e.g.,
ECU or brake system issues).
 Relevance: Both methods are vital for assessing and improving the functional safety
of automotive systems, especially in complex systems like EVs.

The provided text discusses Markov chains, Hazard and Risk Assessment (HARA), and
aspects of software development in the context of functional safety and reliability
engineering for automotive systems, particularly electric vehicles (EVs). Below is a detailed
explanation of these concepts, focusing on their relevance to the provided material and tying
them to the earlier discussion on Event Tree Analysis (ETA) and Cause Consequence
Analysis (CCA).

Markov Chains

Markov chains are probabilistic models used to describe systems that transition between
different states based on probabilities rather than deterministic triggers. They are an extension
of state machines, which are familiar to engineers for modeling systems with defined states
and transitions. In the context of reliability and availability analysis, Markov chains are
particularly useful for quantifying the likelihood of a system moving from a proper
operational state to a failure state.

Key Features of Markov Chains:

1. States and Transitions:

o A Markov chain consists of a set of states (e.g., "proper operation," "partial
failure," "complete failure").
o Transitions between states are governed by transition probabilities, which
represent the likelihood of moving from one state to another.
o Unlike deterministic state machines, Markov chains allow for probabilistic
transitions, including the possibility of moving to a neighboring state without
an explicit trigger.
2. Application in Reliability Engineering:
o Markov chains are used for quantitative reliability and availability analysis
when sufficient data (e.g., failure rates, transition probabilities) are available.
o They model how a system degrades over time or under certain conditions,
such as component wear or random faults.
o For example, in the case of a stuck accelerator (from the ETA/CCA example),
a Markov chain could model states like "accelerator functioning," "accelerator
stuck but controllable," and "uncontrolled acceleration," with probabilities for
transitioning between these states based on driver actions or system responses.
 3. Limitations:
o Markov chains are not suitable for identifying risks unrelated to component
faults (e.g., human errors or environmental factors not tied to hardware).
o They require detailed input data (e.g., failure rates), which may not always be
available.
o While mentioned in ISO 26262 (the functional safety standard for automotive
systems), Markov chains are rarely used directly for functional safety analysis
but are more common in reliability engineering.
4. Relation to ETA/CCA:
o In the context of the stuck accelerator example (Figures 3.3 and 3.4), a
Markov chain could complement the ETA/CCA by quantifying the probability
of reaching critical outcomes (e.g., brake failure or engine not stalling).
o For instance, the probability of transitioning from "brake applied" to "engine
stalled" versus "engine not stalled" could be modeled with transition
probabilities, providing a quantitative layer to the qualitative CCA.

Example Application:

 Consider a vehicle’s powertrain system with states: "Fully Operational," "Degraded

Performance," and "Complete Failure."
 A Markov chain could assign probabilities for transitioning from "Fully Operational"
to "Degraded Performance" (e.g., due to sensor wear) or directly to "Complete
Failure" (e.g., due to a critical ECU fault).
 These probabilities could be derived from historical data or testing, aligning with the
quantitative approach mentioned in the ETA example (e.g.,
P(Y1)P(Y2)P(N4)+P(N1)P(Y2) P(Y_1)P(Y_2)P(N_4) + P(N_1)P(Y_2) P(Y1)P(Y2
)P(N4)+P(N1)P(Y2)).

Hazard and Risk Assessment (HARA)

HARA (Hazard and Risk Assessment, also called Hazard and Risk Analysis) is a systematic
process defined in ISO 26262, Part 3, Chapter 7, used during the concept phase of
automotive product development to identify and evaluate potential hazards and risks. It is a
critical step in establishing safety goals, functional safety requirements, and technical
requirements for automotive systems, especially for EVs.

Key Features of HARA:

1. Purpose:
o HARA identifies all potential hazards associated with a system (e.g.,
powertrain malfunctions) and assesses their risks based on severity, exposure,
and controllability.
o It results in a detailed list of hazards, their effects, and the requirements
needed to mitigate them.
2. Components of HARA:
o Functions and Malfunctions: Identifies the intended functions of a system
(e.g., acceleration control) and potential malfunctions (e.g., stuck accelerator).
 o Conditions and Situations: Considers operational contexts, such as driving
direction, speed, traffic, environmental conditions (e.g., temperature, road
quality), and driver actions (e.g., brake, clutch).
o Severity: Estimates the potential harm of a hazard (e.g., minor injury, severe
injury, or fatality). Malfunctions with no safety impact are assigned severity 0
(Quality Management, QM, issues).
o Exposure: Estimates how often a hazardous situation occurs, based on driving
or operational scenarios (e.g., frequent urban driving vs. rare highway
scenarios).
o Controllability: Assesses the ability of the driver or system to mitigate the
hazard (e.g., can the driver stop the vehicle if the accelerator is stuck?).
o Consequences for Development: Defines safety goals and requirements to
address identified risks.
o Safe State and Tolerance Time: Specifies the desired safe state (e.g., vehicle
stopped) and the time available to achieve it.
3. HARA vs. FMEA:
o HARA focuses on safety-related hazards and their exposure in specific driving
situations. It is scenario-driven and tied to ISO 26262’s functional safety
process.
o FMEA (Failure Mode and Effects Analysis) focuses on component-level
failures and their probabilities, often derived from statistical data. Non-
dangerous malfunctions can still have high risk priority in FMEA if their
probability is high and controllability is low.
o HARA’s exposure ratings are scenario-based, while FMEA’s probabilities are
component-based, though both concepts are related.
4. Table 3.1 (Excerpt from HARA for Powertrain):
o The table likely lists hazards related to the powertrain (e.g., stuck accelerator,
loss of propulsion) with columns for:
 Function (e.g., torque delivery).
 Malfunction (e.g., unintended acceleration).
 Conditions/Situations (e.g., highway driving, wet roads).
 Persons exposed (e.g., driver, pedestrians).
 Severity, exposure, and controllability ratings with justifications.
 Consequences for development (e.g., add redundant torque control).
 Safe state (e.g., vehicle stopped) and tolerance time.
o Unlike FMEA, HARA assigns severity 0 to non-dangerous malfunctions,
excluding them from safety-critical considerations.
5. Relation to ETA/CCA:
o HARA can use ETA to map out the consequences of a hazard (e.g., stuck
accelerator) and evaluate countermeasures, as seen in Figure 3.3.
o CCA extends this by analyzing the causes of specific outcomes (e.g., why the
brake didn’t stall the engine), providing input for HARA’s severity, exposure,
and controllability assessments.
o For example, the stuck accelerator scenario in the ETA/CCA could be part of a
HARA table, where the hazard (unintended acceleration) is evaluated for
severity (e.g., high due to potential crashes), exposure (e.g., moderate in urban
driving), and controllability (e.g., moderate if ECU torque limiting works).
Software Development in Automotive Systems

The text briefly discusses software development in the context of automotive systems,
highlighting its unique challenges and the structured processes developed to ensure quality
and safety. This is particularly relevant for EVs, where software plays a critical role in
controlling systems like the powertrain, battery management, and safety functions.

Key Points:

1. Challenges of Software:
o Invisibility: Unlike hardware, software’s progress, quality, and safety cannot
be visually assessed, making it harder to evaluate.
o Ease of Change: Software can be modified quickly, but frequent changes
often lead to quality or safety issues.
o No Manufacturing Phase: Software development and deployment are
intertwined, except for the act of writing code to a physical device.
2. Structured Development Processes:
o The complexity and invisibility of software have led to highly structured
development processes, driven by decades of failures in quality, cost, or
delivery.
o These processes include configuration management to prevent mixing up
code versions or configurations, ensuring traceability and consistency.
o Examples of process models include those developed by Barry W. Boehm,
such as the Spiral Model, which emphasizes iterative development and risk
management.
3. Relevance to Hardware Engineers:
o Hardware engineers often try to adopt software development processes, but
the fundamental differences between hardware and software (e.g., physical vs.
abstract nature) must be considered.
o Software processes focus on systematic testing, verification, and validation to
ensure functional safety, especially under standards like ISO 26262.
4. Relation to Functional Safety:
o Software is critical for safety functions, such as the ECU’s torque-limiting
feature in the stuck accelerator example (ETA/CCA).
o HARA identifies software-related hazards (e.g., ECU software failure), which
lead to safety requirements (e.g., robust error detection in software).
o Markov chains can model software reliability (e.g., probability of a software
bug causing a failure state), complementing HARA and CCA.

Integration with ETA/CCA

The concepts of Markov chains, HARA, and software development tie into the earlier
discussion of ETA and CCA as follows:

 ETA: Provides a forward-looking analysis of outcomes from an initiating event (e.g.,

stuck accelerator). It is qualitative but can be quantified using probabilities, as in the
 example formula P(Y1)P(Y2)P(N4)+P(N1)P(Y2) P(Y_1)P(Y_2)P(N_4) +
P(N_1)P(Y_2) P(Y1)P(Y2)P(N4)+P(N1)P(Y2).
 CCA: Extends ETA by adding fault trees to analyze the causes of specific outcomes,
enhancing the understanding of why a system behaves a certain way (e.g., why the
brake didn’t stall the engine).
 Markov Chains: Add a probabilistic layer to ETA/CCA by modeling state transitions
(e.g., from "brake applied" to "engine stalled") with transition probabilities, useful for
quantifying reliability.
 HARA: Identifies hazards (e.g., stuck accelerator) and assesses their risks, using
ETA/CCA to evaluate outcomes and countermeasures. It informs software and
hardware requirements to ensure safety.
 Software Development: Ensures that safety-critical software (e.g., ECU torque
control) is developed systematically to meet HARA-derived requirements, with
configuration management to prevent errors.

Example Integration:

For the stuck accelerator scenario:

 HARA: Identifies the hazard (unintended acceleration), assesses its severity (high),
exposure (moderate), and controllability (moderate with ECU intervention), and
defines a safety goal (e.g., limit engine torque within 1 second).
 ETA (Figure 3.3): Maps outcomes based on driver actions (clutch, brake, nothing)
and system responses (ECU torque limiting), identifying safe and critical outcomes.
 CCA (Figure 3.4): Attaches a fault tree to a decision point (e.g., "Does the brake stall
the engine?") to analyze causes like brake wear or ECU failure.
 Markov Chain: Models the probability of transitioning from "accelerator stuck" to
"safe state" (engine stalled) versus "critical state" (uncontrolled acceleration), using
data on brake reliability or ECU performance.
 Software Development: Ensures the ECU software reliably detects accelerator-brake
conflicts and limits torque, with rigorous testing and configuration management to
prevent bugs.