Design reliability 2.0: Safety is Everything

Design Reliability 2.0:
Safety Is Everything
Amir Rahat, VP R&D,
Optima Design Automation

© Optima Design Automation
ENIAC (1946) IBM 7070 (1958) DEC PDP-8 (1965)
Apple I (1976) IBM PC/AT (1984)
All pictures source: Wikimedia
Apple PowerBook 540c (1994)
The 2nd Half Of The 20th Century
2

Apple iPhone 1 2007
Autonomous car – mid 2020’s
The 21st Century
DJI Mavic Pro Drone (2016)
3

The Future
Seeing-eye robot
Self-adjusting furniture
Cyborg organs and limbs
Danger sensing, preventing & reporting
Robotic nanny
Old-people companion
Automatic dog-walker
Physical-object computer games
Automated home delivery & storage
Voice-controlled real-life
4

We Are At The Tipping Point:
The Computers are fleeing their cages
• Moving into the real world entails new responsibilities
• “First, do no harm”
• Safety moves from a negligible aspect to the most important one
• New threats: liability, criminal negligence, jail, death-toll
• The tectonic shift will be even bigger than the shift into low-power
5© Optima Design Automation
The stakes have gone up dramatically.
We need to rethink our methodologies.
Picture source: Wikipedia

The Automotive Industry Is Leading The Way
• Perfect example of computers in the real world
• Stepping-stone development through the different levels
• Level 1-3 already implemented
• Safety standard published in 2011
• ISO-26262: Road vehicles - Functional safety
• Second revision underway, due 2018
• First ISO-26262 uProcessor certification in 2012
• Freescale MPC5643L certified by Exida
Picture source: sae.org
6

New Validation Paradigms: Facets of Trustworthiness
• Safety: The ability to operate without causing harm to anything or anyone
• Reliability: The ability to operate correctly
• Availability: The ability to operate whenever required
• Resilience: The ability to safely withstand hazards posed by nature
• Security: The ability to overcome hazards posed by malice or accident
Adapted from The Trustworthy Software Framework, http://tsfdn.org/ts-framework/
Also see dependability; RAMS (acronym for Reliability, Availability, Maintainability, and Safety)
7
Note: These may sometimes conflict. Need to reach the correct balance

Mapping Trustworthiness to Automotive Safety
• ISO-26262 addresses:
• Safety: The ability to operate without causing harm to anything or anyone
• Availability: The ability to operate whenever required
• Resilience: The ability to safely withstand hazards posed by nature
• A future standard on SOTIF (Safety Of The Intended Function) addresses:
• Reliability: The ability to operate correctly
• A future ISO/SAE standard on Security Process addresses:
• Security: The ability to overcome hazards posed by malice or accident
© Optima Design Automation 8

What Does All This Mean For You?
• This is new to the computing/smartphone industry
• Reinventing the design methodology… again…
• Remember the low power revolution?
• Based on System Engineering
• Safety is a mindset…
• ISO 26262 standard: “Road vehicles — Functional safety”
• Adaptation of IEC 61508 generic “everything” safety standard
• And then there are all these other safety standards:
Picture source: Pixabay
•
•
•
• IEC 62304 (Medical device software)
• IEC 61511 (For the process industry sector)
• IEC 61513 (Nuclear power plants safety)
• IEC 62061 (Safety of machinery)
• ISO 13849 (Safety of machinery)
• EN 5012x (Railways)
• DO-178 (Aviation)
• DO-254 (Aviation)
• IEC 60730 (household/white goods)
• IEC 61800 (power drive)
• IEC 60601 (medical equipment)
• MIL-STD-882E (DoD)
• FMVSS (Federal Vehicle Safety)
• AUTOSAR (SW)
• MISRA C (SW)
•
•
•
You need to think about safety

• It all starts with system-engineering & structured methodology
• So let’s get started…
Balancing Cost Vs. Safety Navigating the forest of standards

End of the exposition
Next: what can the Automotive industry teach us?

What System Safety Does US-NHTSA Require?
• Ensure fail-safe
• Follow industry standards (ISO-26262) and relevant & applicable standards and processes
from aviation, space, military, etc.
• Do hazard analysis and safety risk assessment at all levels
• Provide redundancies & safety strategies for system malfunction
• Enforce proper software development process, verification and validation
• Monitor the evolution, implementation, and safety assessment of AI, machine learning,...
• Link Design decisions to the assessed risks impacting safety-critical system functionality
• Test, validate and verify everything both as individual subsystems and as part of the
entire vehicle architecture
• Fully document the entire process with traceability
https://www.transportation.gov/sites/dot.gov/files/docs/AV%20policy%20guidance%20PDF.pdf p.20

ISO-26262 Basics
• ISO-26262 defines functional safety as the:
“Absence of unreasonable risk due to hazards caused by malfunctioning
behaviour of E/E systems”
• Risks come from systematic failures and random hardware failures
• Process-based approach:
• Functional safety management, verification, validation, confirmation and
relations with suppliers
ISO-26262: a process to lower risks below a preset threshold

The Process: The 26262 Safety Lifecycle
14
© Optima Design AutomationPicture source: ISO-26262

Required HW Product Development Process Steps
1510/19/2016 © Optima Design Automation
Picture source: ISO-26262

The Stages Of ISO-26262 Risk Analysis
1. Identify the hazards and assess the risks of each one
• Likelihood, potential damage, etc.
2. Classify the hazards into buckets based on 3 criteria:
• Severity of possible injuries
• Exposure to the possibility of the hazard happening
• Controllability by the driver to prevent the injury (e.g., 0 for automatic cars)
• Each bucket gets a budget of acceptable risk
3. Specify safety mechanisms that mitigate unacceptable risks by:
• Preventing risks; or
• Detecting & reacting to emerging risks
4. Analyze the design and determine its residual safety level
• Is it safe enough for the task at hand?
This is the key to ISO-26262 functional safety
Pictures source: Pixabay, fantasticpixcool, Wikimedia

1. Identify the hazards and assess the risks of
each hazard
Malfunction
and
Identify and categorise hazards triggered by malfunctionsPictures source: Flickr, Pixabay, Wikimedia

A Cautionary Tale
• GM had an ignition switch that turned from “run” to “accessory” when touched
• What are the risks if an ignition switch suddenly turns off?
• Car stalls on highway
• No engine
• Limited driver control
• what else?
• Unrelated, GM was concerned about airbags exploding while the car is parked
• So they added a clever safety: airbag is inactivated when the switch is off
• This combination caused 100-200 deaths in many accidents
• Google “General Motors ignition switch scandal”

Picture source: atlantamagazine.com

2. Classify the hazards into buckets based on
3 criteria
• Exposure
• E0: Incredible (e.g., an airplane landing on a highway) – Ignore!
• E1: Very low probability
• E2: Low probability (<1%)
• E3: Medium probability (1-10%)
• E4: High probability (>10%)
• Severity (potential harm)
• S0: No injuries (limited to material damage) – Ignore!
• S1: Light and moderate injuries
• S2: Severe and life-threatening injuries (survival probable)
• S3: Life-threatening injuries (survival uncertain), fatal injuries
• Controllability (ease to avoid)
• C0: Controllable in general – Ignore!
• C1: Simply controllable
• C2: Normally controllable
• C3: Difficult to control or uncontrollable
C1 C2 C3
S1
E1 QM QM QM
E2 QM QM QM
E3 QM QM A
E4 QM A B
S2
E1 QM QM QM
E2 QM QM A
E3 QM A B
E4 A B C
S3
E1 QM QM A
E2 QM A B
E3 A B C
E4 B C D

Picture source: ISO-26262
3. Specify safety mechanisms that mitigate
unacceptable risks

Functional Safety Requirements
• Control internal failures of the hardware
• Control or tolerate failures external to the element
• Comply with the safety requirements of other elements
• Detect and signal internal or external failures
• Meet the target values for random hardware failures
• Avoid specific behaviours
• For example, “a particular sensor shall not produce an unstable output signal”
• Implement the intended functionality (SOTIF)

Sources Of Risk
Risk
SWHW PermanentTransient
Systematic
failures
Random HW
failures
Addressed by proper processes for
requirements, design, engineering &
management
Addressed in the following foils
4. Analyze Your Design And Assess Its Safety
Level

The Two Types Of Naturally-Occurring Faults
Soft Error/Transient Fault Bit flip Hard Error/Permanent Fault
Picture source: : shutterstock (licensed), intechopen, jes.ecsdl.org

The Two Types Of Naturally-Occurring Faults
Soft Error/Transient Fault Bit flip
• Mechanism: cosmic radiation
flips a register logic value of
• Effect: The register stays flipped
until a new value is set
• Detection: requires redundancy
• Prevention of harm:
• Hardening, e.g. more capacitance
• Redundancy: 2X, 3X, 9X
Hard Error/Permanent Fault
• Mechanism: unexpected
damage e.g. due to environment
(heat, vibrations, dust)
• Effect: the failure is permanent
• Detection: frequent self-testing
• Prevention of harm:
• Graceful degradation
• Redundancy: 2X, 3X, 9X

Picture source: CNN, EETimes

Classification of Faults in safety-related HW
Can it do any harm?
It is a Safe Fault
(SF, λS)
Is it
detected
?
Is there
a
relevant
SM?
Is it
perceived
by the
driver?
It is a Detected
Fault(λMPF,D)
It is a Single-point
Fault (SPF, λSPF)
Is it
detected
by the
SM?
Is it
perceived
by the
driver?
It is a Residual
Fault (RF, λRF)
It is a Latent Fault
(MPF,L λMPF,L) It is a Perceived
Fault (λMPF,P)
λ = λSPF + λRF + λMPF,D + λMPF,P + λMPF,L + λS
Never By itself
Only with other faults
No
No
No
Yes
Yes
Yes
No
No
Yes
Yes
(SM = Safety
mechanism)
Failure rate (λ) is the frequency with
which an engineered system or
component fails, expressed
in failures per unit of time. (Wikipedia)

Q: How to tell how well we cope with random hardware failures?
5-8: HW Architectural Metrics
• SPFM – Single-point fault metric: 1 - (λSPF + λRF) / λ
• ≥90% for ASIL B, ≥97% for ASIL C, ≥99% for ASIL D
• LFM – Latent-fault metric: 1 - λMPF,L / (λ - λSPF - λRF)
• ≥60% for ASIL B, ≥80% for ASIL C, ≥90% for ASIL D
A: Using two metrics:
Computed with Diagnostic coverage or estimated

Can it do any harm?
It is a Safe Fault
(SF, λS)
Is it
detected
?
Is there
a
relevant
SM?
Is it
perceived
by the
driver?
It is a Detected
Fault(λMPF,D)
Fault (SPF, λSPF)
Is it
detected
by the
SM?
Is it
perceived
by the
driver?
It is a Residual
Fault (RF, λRF)
Fault (λMPF,P)
Never By itself
No
No
No
Yes
Yes
Yes
No
No
Yes
Yes
(SM = Safety
mechanism)
SPFM – Single-point fault metric: 1 - (λSPF + λRF) / λ
≥90% for ASIL B, ≥97% for ASIL C, ≥99% for ASIL D

Can it do any harm?
It is a Safe Fault
(SF, λS)
Is it
detected
?
Is there
a
relevant
SM?
Is it
perceived
by the
driver?
It is a Detected
Fault(λMPF,D)
Fault (SPF, λSPF)
Is it
detected
by the
SM?
Is it
perceived
by the
driver?
It is a Residual
Fault (RF, λRF)
Fault (λMPF,P)
Never By itself
No
No
No
Yes
Yes
Yes
No
No
Yes
Yes
(SM = Safety
mechanism)
LFM – Latent-fault metric: 1 - λMPF,L / (λ - λSPF - λRF)
≥60% for ASIL B, ≥80% for ASIL C, ≥90% for ASIL D

5-9: Violations Due To Random HW Failures
Is it
under
the
target?
For every safety goal:
Sum the probabilities of all
faults that can violate it
Acceptable
Safety level
Unacceptable safety level -
must be fixed
NoYes
10-8 per hour: ASIL-D
10-7 per hour: ASIL-C/B

Risk Mitigation Options
• Error detection and correction schemas for memories and busses
• Redundancy
• Hard errors: SW or HW tests
• Soft errors: flop hardening
Amir Rahat, Optima Design Automation Ltd
© All rights reserved

In
Out
Err
In
Out
Error Corrected
Majority
Gate
Dual Error
In
Out
Error Corrected
Majority
Gate
Dual Error
TMR
• 2X = DMR = lockstep
• Single error detection
• No correction capability
• >2X the costs
• 3X = TMR
• Single error correction
• Dual error detection (if > single bit)
• >3X the costs
• 9X = TMR of TMR’s
• Compares 3 implementations
• Protects against design errors, too
• >9X the costs
ProtectionByRedundancy
TMR
TMR

ProtectionByTest(HEonly)
• Run a test (SW or HW) intermittently
• Compare its results to the expected results
• If the test fails – enter and maintain the safe state
• Probability of error detection depends on:
• Time to detection (=time between intermittent test
runs)
• Probability of detecting a fault (=test coverage)
• Measurement of test coverage is required

How Does Selective Hardening Work?
Provided by the
simulation
Decided by the
designer
Based on flop
selection & vendor
datasheet
Calculated
Only works with accurate, reliable sensitivity results!
Now, do the tradeoff

Summary - Protecting The Design From Faults
Memory or
Logic?
Pick appropriate
ECC
Redundancy
OK?
OK to
implement
Pick a redundancy
mechanism
SE or HE?
(can do both)
Focus on registers Focus on all nodes
Need SE selective
hardening
Harden all flops
Pick the right DFT
technique
Create a
functional test
Need HE coverage
metric
Is full hardening
OK?
Disruptive test
OK?
Memory Logic
Too expensiveOK
SE
HE
Unsafe
OKOK
expensive
OK to implement,
but expensive
OK to implement,
but expensive
OK to implement,
but disruptive

Picture source: Pixabay

Simulation*-Based Analysis
What do
you need?
How accurate
should it be?
Guess the
impact (no
way to check)
Guard-band
the results to
account for
errors
Identify ways
to improve
coverage
Guard-band the
results to
account for
errors
Identify ways
to improve
coverage
Accurately
calculate the
resulting risks
Collect
accurate
coverage data
How accurate
should it be?
Use “expert
opinion” to
select flops to
harden
Partially
simulate and
select flops to
harden
Exhaustively
simulate to
select flops to
harden
Partially
simulate and
get an
indication
Exhaustively
simulate to
measure
coverage
HE Coverage metric
Very
accurate
Sortof
Notvery
Sort of
Very
accurate
* (including Emulation)
SE Selective hardening
Must run 1M flops, 200 errors per flop
(= 200M simulations) in machine-weeks

Report results
Using Fault Simulations
Design (RTL or Gate Level) in a HDL (Verilog or VHDL)
Test environment (test-bench, SW or input values)
Comparator
SE Sensitivity Monitor:
Did the fault impact a safety goal?
Faulty Machine Simulator Good Machine Simulator
HE Coverage Monitor:
Was the fault detected?
SE: Which flop flips and when?
HE: Which node breaks and how?
Fault details
Report results

Report results
Using Fault Simulations
Design (RTL or Gate Level) in a HDL (Verilog or VHDL)
Test environment (test-bench, SW or input values)
Comparator
SE Sensitivity Monitor:
Did the fault impact a safety goal?
Faulty Machine Simulator Good Machine Simulator
HE Coverage Monitor:
Was the fault detected?
Fault details
Report results
Repeat for all
relevant faults
(assuming you know them…)

CAD/EDA – Automatic Safety
• Manage the specification and implementation of Safety Requirements
• Ensure design protection from faults, across all levels of hierarchy & IPs
• Assist in selecting and applying the right safety goals
• Taking into account the different types of design components
• Calculate goal risk levels and safety metrics (e.g., SPFM & LFM)
• Support all fault models, soft and hard
• Simulate millions of faults quickly and accurately
• Classify each fault to the correct category
• Provide documentation for safety audits

Optima’s Soft Error Safety Tool
• Optima developed an EDA solution for Soft Errors
• Based on an ultra-fast Fault simulator
• Supports all the automation requirements mentioned
• Runs 200M simulations in machine-weeks with 100% confidence
• Manages the overall design flow
• Follows the optimal safety methodology
• Creates an exhaustive campaign
• Runs it and generates reports
• Enables selective hardening with easy tradeoff what-ifs
• Generates all the 26262 metrics
• The only comprehensive soft-error safety tool available
• Hard Error support to be released soon

The Work Flow In A Nutshell
• To best balance safety and costs, follow this flow:
Specify the HW Safety Requirements
At all design revisions & abstraction levels:
Classify the Faults in the safety-related HW
Compute the HW Architectural Metrics
Optimize the tradeoff between FIT, area and power

Summary – What Did We learn?
• The Computers are fleeing their cages and going in the real world
• So safety moves from a negligible aspect to the most important one
• This means reinventing the design methodology… again…
• Must focus on Safety, Reliability, Availability, Resilience, Security
• The automotive industry is leading the way - what can it teach us?
• System-engineering & a process to lower risks below the threshold:
1. Identify the hazards and assess the risks of each one
2. Classify the hazards into buckets based on Severity, Exposure & Controllability
3. Specify safety mechanisms that mitigate unacceptable risks
4. Analyze the design and assess its residual safety level => verification and testing
Picture sources: Wikimedia, HVC

Questions?
Thank you for your attention!
amir@optima-da.com

Design reliability 2.0: Safety is Everything

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Design reliability 2.0: Safety is Everything

Similar to Design reliability 2.0: Safety is Everything (20)

Recently uploaded

Recently uploaded (20)

Design reliability 2.0: Safety is Everything