NXP and the NXP logo are trademarks of NXP B.V. All other product or service names are the property
of their respective owners. © 2017 NXP B.V.
PUBLIC
FUNCTIONAL SAFETY MANAGER
MATHIEU BLAZY-WINNING
DESIGNING FOR ADVANCED
FUNCTIONAL SAFETY
REQUIREMENTS
AMF-AUT-T2805 | AUGUST 2017
PUBLIC 1
AGENDA• Overview of ISO 26262 Standard
• NXP Approach to ISO 26262
• Conclusion
PUBLIC 2
FROM AUTOMOTIVE … TO SAFE & SECURE MOBILITY
SEAMLESS CONNECTED
MOBILITY EXPERIENCE
ADVANCED DRIVER
ASSISTANCE
SELF-DRIVING
ENERGY EFFICIENCY
Enjoying Life.
One hour per day
in the car
Saving Lives.
1.3M Road Fatalities
Every Year
Reducing CO2.
EU mandates 20%
reduction by 2020
PUBLIC 3
Every year!
~1.3 m fatalities
>50 m people seriously injured
>$3 trillion cost of road accidents
>90% caused by human mistakes
We need to get the
Human Factor
out of the equation!
Critical
Reasons
Number %
Driver 2,046,000 94%
Vehicles 44,000 2%
Environment 52,000 2%
Unknown 47,000 2%
Total 2,189,000 100%
Driver-Related
Critical Reasons Number %
Recognition Error 845,000 41%
Decision Error 684,000 33%
Performance Error 210,000 11%
Non-performance
Error (e.g. Sleep)
145,000 7%
Other 162,000 8%
Total 2,046,000 100%Data source: NMVCCS
ROAD TRAFFIC ACCIDENTSTHE CAUSES
PUBLIC 4
Elements of a Safe System
VEHICLE SAFETY: Zero accidents by human error (ADAS & SOTIF)
SECURITY: Zero accidents by system hacks
FUNCTIONAL SAFETY: Zero accidents by system failures (ISO 26262)
DEVICE RELIABILITY: Zero components failures (robust product)
SECURITY
DEVICE
RELIABILITY
FUNCTIONAL
SAFETY
VEHICLE
SAFETY
SOTIF: Safety of the intended functionality
PUBLIC 5
Overview of
ISO 26262 Standard
5
PUBLIC 6
Functional Safety Standards
• ISO 26262 is the adaptation of IEC 61508 to comply with needs specific to electrical and/or electronic (E/E) systems within road vehicles.
• ISO 26262 addresses possible hazards caused by malfunctioning behavior of E/E safety-related systems.
• Addresses risks from systematic failures and random hardware failures.
• System safety is achieved through a number of safety measures.
• ISO 26262 provides an automotive-specific risk-based approach to determine integrity levels [Automotive Safety Integrity Levels (ASIL)].
• ISO 26262 uses ASILs to specify applicable requirements of ISO 26262 so as to avoid unreasonable residual risk.
Reference ISO 26262-1:2011
PUBLIC 7
ISO 26262 Product Development
• ISO 26262 compliance is achieved between vehicle manufacturers, Automotive suppliers (Tier 1), semiconductor suppliers and IP providers
Reference ISO 26262-2:2011
Focus of presentation
Q: But who does what?
PUBLIC 8
Part 3 Concept
8
PUBLIC 9
Exposure ControllabilitySeverity
ASIL
How often is it likely to happen? Can the hazard be controlled?How much harm is done?
Concept
Determining ASIL
PUBLIC 10
Hazard Analysis and Risk Assessment (HARA)
• Identify and categorize the hazards that can be triggered by malfunctions in the system
• The Risk Assessment is carried out using three criteria
− Severity – how much harm is done?
− Exposure – how often is it likely to happen?
− Controllability – can the hazard be controlled?
Reference ISO 26262-3:2011
Concept
PUBLIC 11
Determination of ASIL and Safety Goals
• For each Hazardous event, determine the ASIL based on Severity, Exposure & Controllability
• Then formulate safety goals to prevent or mitigate each event, to avoid unreasonable risk
Reference ISO 26262-3:2011
Concept
Q: So which ASIL
should I target in
my IC or IP?
PUBLIC 12
Functional Safety Concept
• The functional safety concept addresses:
− Fault detection and failure mitigation
− Safe State transitioning
− Fault tolerance mechanisms
− Driver warning
Concept
Q: This is a top down approach, typically components & IP developed as Safety Element out of Context (SEooC), how to make assumptions?
Reference ISO 26262-3:2011Note: An SEooC is a safety-related element which is not developed for a specific item. This
means it is not developed in the context of a particular vehicle.
PUBLIC 13
Part 4 System
13
PUBLIC 14
Safety Mechanisms & Faults
• A safety mechanism is a technical solution implemented by E/E functions or elements, or by other technologies, to detect faults or control failures in order to achieve or maintain a safe state
• Safety mechanisms are implemented to prevent faults from leading to single-point failures or to reduce residual failures and to prevent faults from being latent
− multiple-point fault is a individual fault that, in combination with other independent faults, leads to a multiple-point failure.
• Safety Mechanisms can take effect during
− Power up (pre-drive checks)
− During operation
− During power-down (post-drive checks)
− Part of maintenance.
System
Q: How to decide where to
implement safety mechanisms?
… in HW or SW, in system or
component or IP…
Reference ISO 26262-1:2011
PUBLIC 15
Fault Detection & Reaction Times
• Diagnostic test interval
− amount of time between the executions of online diagnostic tests by a safety mechanism
• Fault reaction time
− time-span from the detection of a fault to reaching the safe state
• Fault tolerant time interval
− time-span in which a fault or faults can be present in a system before a hazardous event occurs
• Multiple-point fault detection interval
− time span to detect multiple-point fault before it can contribute to a multiple-point failure
Reference ISO 26262-1:2011
System
Q: How to know which times to use?
1ms, 10ms, 100ms, 1sec, 1hr, several hours etc
PUBLIC 16
Part 5 Hardware
16
PUBLIC 17
Target Metrics for ASIL
• Associate the following target metrics to each safety goal
− Single-point fault metric (SPFM)
− Latent-fault metric (LFM)
− Probabilistic Metric for random Hardware Failures (PMHF)
Reference ISO 26262-5:2011
Hardware
Q: Which portion
of PMHF can an
IC or IP use?
Q: Which faults to
consider? How to
justify diagnostic
coverage? …
Some guidance in
Part 5 Annex D…
PUBLIC 18
Hardware Integration & Testing Hardware
Q: Fairly standards tests, except for fault injection?
Reference ISO 26262-5:2011
PUBLIC 19
Part 6 Software
19
PUBLIC 20
SW Safety Mechanisms Software
Reference ISO 26262-6:2011
PUBLIC 21
Part 7 Production
21
PUBLIC 22
Part 7 Production
• Develop and maintain a production process for safety-related elements or items that are intended to be installed in road vehicles.
− Typically existing production processes aligned with ISO TS 16949 are also well aligned with ISO 26262 requirements
• In addition, the compliance with safety-related special characteristics may be required
− Examples of such safety-related special characteristics are
specific process parameters (e.g. temperature range or fastening torque)
material characteristics
production tolerance
Configuration
• Also, safety impact analysis of changes or field returns is required during production -> augmenting standard processes to comply.
Production
Reference ISO 26262-7:2011
PUBLIC 23
ISO 26262 2nd Edition
23
PUBLIC 24
ISO 26262 2nd Edition
• The 2nd edition of ISO 26262 is planned for release in 2018.
• Most notable changes
− Scope now for series production road vehicles, except mopeds.
− Specific content added for Trucks, Buses, Trailers, Semitrailers and motorcycles (although very minimal)
− Part 11 guideline added for Semiconductors
− Part 12 added for motorcycles (mapping of MSIL to ASIL)
− Interaction between safety and security organizations mentioned (no specifics)
− Method for dependent failure analysis provided in multiple examples
− Guidance for fault tolerance
− Part 8.13 Hardware Qualification reworked to focus on non ISO 26262 developed hardware
− Overall improvements to clarify understanding
• Limited new content towards fail operational / autonomous vehicles indicating not yet mature enough in industry to standardize
Disclaimer: Above notes from DIS version, may change in final release
PUBLIC 25
NXP Approach to
ISO 26262
25
PUBLIC 26
Functional Safety Standards
Generic
Standard
IEC61508
Industrial
Automation
Rail Transport
Automotive
Aeronautic
1980 1985 1990 1995 2000 2005 2010 2015
ISO 26262
IEC 61508IEC 61508
Ed. 2.0
IEC 61508
Ed. 2.0
EN 50155
IEC 61508
EN 5012X
EN 50159
(IEC 61508)
DO 178
DO 178AARP 4761 DO 254
Medical
IEC 60601
Ed. 3.0
Select products are being defined and designed
from the ground up to comply with
ISO 26262
Note: Some products enabled for IEC 61508 Ed.
2.0 & ISO 13849
DO 178B
ARP 4754
DO 178C
ARP 4754A
IEC 61508
IEC 61511
IEC 62061
ISO 13849
PUBLIC 27
NXP’s Safe Assure Program
27
• Launched SafeAssure initiative in September 2011
focusing on NXP’s functional safety solutions
• NXP Development Processes are aligned with ISO
26262 since 2013 across product lines
− BCaM7 deployment will align at BU Auto level
• 100+ Products being developed to target ISO 26262:
Aug 2012 AMP HW – Leopard (MPC564xL) 32-bit MCU – Certified
by Exida
2013 AMP SW – First release of Safety MCAL (sMCAL)
2014 AAA HW – Analog – PowerSBC
Many more products are in the development pipeline and will come
to completion in the years to come
http://www.nxp.com/safeassurehttp://cache.freescale.com/files/32bit/doc/support_info/C26262_MPC5643L.pdf
PUBLIC 28
Example Interaction Between Car OEM, Tier 1 & Tier 2 (NXP)
OEM
• Safety Architecture
• Safety Concept
• ASIL Classification of Functions
Tier 1
• HW / SW products
Tier 2 Supplier - NXP
• Item definition
• Hazard analysis and risk assessment
• Safety Goals
• Functional Safety ConceptISO26262 Safety
Requirements &
DIA
Safety
Requirements &
DIA
Safety Manual &
Safety Analysis
Relevant
scope of
ISO26262
high
Fo
un
datio
n Product Safety Mechanisms
(implemented in offering, described in
Safety Manual, quantified/qualified by
Safety Analysis)
Development Process & Methods
Quality & Quality Data
Relevant
scope of
ISO26262
medium
Overall ISO 26262 compliance is
achieved together, we each own a
piece of the puzzle
NXPFunctional Safety Focus
Safety Element out of Context
Safety Manual &
Safety Analysis
PUBLIC 29
HW & SW Components developed as SEooC
Reference ISO 26262-10:2012Applicable to HW Component developed as SEooC
(4-6) Safety Concept
(RS)
(4-7) Safety Concept
(AS)
Safety Manual includes all HW & SW
requirements on system level (Assumptions)
as well as Safety Concept description
PUBLIC 30
Tailoring of ISO26262 to Component developed as Safety
Element out of Context (SEooC)
HW
Component
Developed as
SEooC
Reference ISO 26262-10:2012Applicable to Component developed as SEooC
SW
Component
Developed as
SEooC
PUBLIC 31
ISO 26262 Product Development - BCaM7
• ISO 26262 compliance is achieved between vehicle manufacturers, Automotive suppliers (Tier 1), semiconductor suppliers and IP providers
NPI LIFECYCLE
TO CES RQ ECQS
CONCEPT DEFINITION PLANNING EXECUTION CLOSURE
PROJECT LIFECYCLE
PDA PPA R PCPCAPI
(4-6) Safety Context
(4-7) Safety Concept
(5-6) Requirements
Specifications (RS)
(5-7) Detailed Design
Specifications (DDTS)
(5-8,9) Initial Safety
Analysis
(5-10) Validation
Testing
(5-7) Block Level
Verification Testing
(8-13) Qualification
Testing
(5-7) Chip Level
Verification Testing
Implement
Safety Documentation Silicon TestingSimulation TestingFunctional Documentation
Diagram Color Schema Development Flow Requirement Traceability
Fault Injection Testing
Fault Injection Testing
Fault Injection Testing
Input Requirements
Standard
Customer
Marketing (MRD)
Internal
Product
Requirements (PRD)
Architectural
Specification
Data Sheet
Reference
Manual
Safety Manual
FMEDA, FTA,
DFA
(7-5) Production
Testing
Customer Documents
Input Document
PI Gate
Define product type
QM or ISO 26262
R Gate
Product Functional Safety
Assessment Report &
Safety Case
PUBLIC 32
NXP Processes aligned with ISO 26262
• NXP ISO 26262 process complies with all applicable ISO 26262 ASIL D requirements for HW or SW SEooC development
• One process for all products, regardless of safety architecture ASIL target
• Only difference is for Confirmation Measures which are tailored to ASIL target
ISO 26262 NXP Process ASIL A ASIL B ASIL C ASIL DPart 2
ManagementSafety Plan, Safety Case, Confirmation Measures Yes
Part 3 Concept OEM / Tier 1 responsibility NA
Part 4 SystemSystem assumptions & Safety Requirements –
HW/SWYes, only partially applicable
Part 5 HardwareHW – Safety requirements traced to
implementation and testingYes
Part 6 SoftwareSW – Safety requirements traced to
implementation and testingYes
Part 7 Production Standard processes, aligned with ISO 26262 Yes
Part 8 Processes Standard processes, aligned with ISO 26262 Yes
Part 9 Analysis FMEDA, FTA & DFA Yes
Part 10 GuidelineSEooC Development & application of ISO 26262
to componentsYes, SEooC development
PUBLIC 33
NXP ISO 26262 Confirmation Measures
• NXP performs ISO 26262 Confirmation Reviews (CR), Audit and Assessment as required by ISO 26262 for SEooC
development
• Confirmation Measures (CM) performed depending on ASIL
• All checks executed with independence level I3 by NXP Quality organization
• NXP Assessors certified by SGS-TÜV Saar as Automotive Functional Safety Professional (AFSP)
• NXP CM process certified by SGS-TÜV Saar as ISO 26262 ASIL D
Confirmation
MeasuresASIL A ASIL B ASIL C ASIL D
CR Safety Analysis Yes Yes Yes Yes
CR Safety Plan Yes Yes Yes
CR Safety Case Yes Yes Yes
CR Software Tools Yes Yes
Audit Yes Yes
Assessment Yes YesNote: The following confirmation reviews are not applicable: hazard analysis and risk assessment,
item integration and testing, validation plan & proven in use argument
PUBLIC 34
TOMORROW: ENABLING THE SAFE & SECURE CONNECTED
CAR
Radar
Vision
Secure V2X
SENSE
Processing
Sensor Fusion
Security
THINK
Powertrain
Chassis
Braking
ACT
Digital Networking
Infrastructure
Security
BIG DATASecureNetwork
Secure
Network
Surround ViewBlind Spot
Detection
Park A
ssist
Rear
Collision
Warning
Park Assistance/
Surround View
Surround
View
Park A
ssist
Cross
Traffic
Alert
Traffic Sign
Recognition
Lane Departure
Warning
Emergency Braking
Pedestrian Detection
Collision Avoidance
Adaptive
Cruise Control
Secure Connected, Self-Driving Cars will
Save >1,3M Road fatalities globally
NXP Offers Complete Safe &
Secure ADAS System….
…including Big Data
Infrastructure
PUBLIC 35
Where the Failures Come From
• Typically, dangerous failures in a safety system come from a combination of the following
− Development bugs – Software or hardware
− Insufficient system safety architecture
− Transient failures in semiconductors, primarily SRAM – very high rate of occurrence
− Permanent failures in hardware
• For a MCU the break down of Failures is typically:
Failure Type per hour FIT %
MCU SRAM Transient Failure rate 7.00E-07 700 70.00%
MCU FF Transient Failure rate 2.00E-07 200 20.00%
MCU Package Permanent Failure rate 8.00E-08 80 8.00%
MCU Die Permanent Failure rate 2.00E-08 20 2.00%
MCU Total Failure rate 1.00E-06 1000 100%
1.00E-05
1.00E-06
1.00E-07
1.00E-08 MCU ASIL B
1.00E-09 MCU ASIL D
1.00E-10
MCU Raw
Residual Failure rate
Note: Assumption - MCU is allocated only 10% of System ASIL target
PUBLIC 36
MCU Safety Context
• Applications have different safety requirements driven by different safety contexts,
but the need for safe SW execution is common across all
• The objective is to make SW execution safe to achieve ASIL B or ASIL D
depending on target market
1.00E-05
1.00E-06
1.00E-07
1.00E-08 MCU ASIL B
1.00E-09 MCU ASIL D
1.00E-10
MCU Raw
Residual Failure rate
ASIL B ASIL D
Fault Detection Time Interval
Diagnostic Coverage
(transient & permanent faults)90% 99%
Residual Failure rate 1 x 10-8 / h 1 x 10-9 / h
Start-up /
Shut-down
periodic test
Diagnostic Coverage
(permanent faults)60% 90%
10 msDetect
incorrect
operation
during
runtime
MCU HW to support SW Independence MPUNote: Assumption - MCU is allocated only 10% of System ASIL target
PUBLIC 37
Defining the Safety Concept
• Objective
− Define how ASIL targets will be achieved between a mix of on-chip HW safety measures and system level safety measures (HW/SW)
• ISO 26262-5 Annex D – Elements related to HW Components
− Low application dependency: Power, Clock, Flash, SRAM & Processing Unit
− High application dependency: Digital IO & Analog IO
Reference ISO 26262-5:2011
PUBLIC 38
Module Classification - Safety
• Each module on the MCU is classified as Safety Related or Not Safety Related Elements in ISO
26262-5, Table
D.1
MPC5744P
FMEDAMPC5744P Module
Part of
Software
Execution
Function
Safety
MechanismComments
Power Management Controller (PMC) YES
Power Control Unit (MC_PCU) YES
Phase Lock Loop (2 x PLL) YES
Clock Monitor Unit (5 x CMU) YES
Clock Generation Module (MC_CGM) YES
External Oscillator (XOSC) YES
Internal RC Oscillator (IRCOSC) YES
Embedded Flash Memory (c55fmc) YES
Flash Memory Controller (PFLASH) YES
End-to-end Error Correction Code (e2eECC) YES
System SRAM YES
RAM Controller (PRAMC) YES
End-to-end Error Correction Code (e2eECC) YES
Main Core_0 (e200z4251n3) YES
Checker Core_0s (e200z424) (Delayed Lockstep) YES
Crossbar Switch (XBAR) YES
JTAG Controller (JTAGC) Not Safety Related module - Debug logic
Nexus debug modules (NXMC, NPC, NAL & NAP) Not Safety Related module - Debug logic
Cyclic Redundancy Check (CRC) YES
Fault Collection and Control Unit (FCCU) YES
Memory Error Management Unit (MEMU) YES
Self-Test Control Unit (STCU2) (includes MBIST & LBIST) YES
Register Protection (REG_PROT) YES
CAN (3 x FlexCAN) Peripheral module - High application dependency (failure rates only)
Serial Interprocessor Interface (SIPI) Peripheral module - High application dependency (failure rates only)
10/100-Mbps Ethernet MAC (ENET) Peripheral module - High application dependency (failure rates only)
Peripheral Bridge (2 x PBRIDGE) Peripheral module - High application dependency (failure rates only)
System Integration Unit Lite2 (SIUL2) Peripheral module - High application dependency (failure rates only)
Analog to Digital Converter (4 x ADC) Peripheral module - High application dependency (failure rates only)
Wakeup Unit (WKPU) Peripheral module - High application dependency (failure rates only)
FlashNon-Volatile
Memory
Volatile Memory SRAM
Peripheral
Analogue I/O and
Digital I/O
Power
Clock
Power Supply
Clock
Communication
(External)
CoreProcessing Unit
PUBLIC 39
Realizing the MCU Safety Concept - MPC5744P
Power Monitoring
Clock Monitoring
ECC on
SRAM &
Flash
Processing Unit - Dual Core Lockstep
ECC
on
buses
Redundant use of IO & Application checks
Fault
Tolerant
Com.
PUBLIC 40
Defining the Safety Concept – RADAR Example
• Objective
− Define how ASIL targets will be achieved
between a mix of on-chip HW safety
measures and system level safety
measures (HW/SW)
• ISO 26262-5 Annex D – Elements
related to HW Components
− Low application dependency: Power,
Clock, Flash, SRAM & Processing Unit
− High application dependency: RF, Digital &
Analog IO
PUBLIC 41
Customer
Deliverables
41
PUBLIC 42
NXP SafeAssure Products
To support the customer to build his safety system, the following deliverables are provided as standard for all ISO 26262
developed products.
• Public Information available via NXP Website
− Quality Certificates
− Safety Manual
− Reference Manual
− Data Sheet
• Confidential Information available under NDA
− Safety Plan
− ISO 26262 Safety Case
− Permanent Failure Rate data (Die & Package) - IEC/TR 62380 or SN29500
− Transient Failure Rate data (Die) - JEDEC Standard JESD89
− Safety Analysis (FMEDA, FTA, DFA) & Report
− PPAP
− Confirmation Measures Report (summary of all applicable confirmation measures)
PUBLIC 43
Safety Manual
43
PUBLIC 44
Safety Manual
Objective
• Enables customers to build their safety system
using the MCU safety mechanisms and defines
system level HW & SW assumptions
• Simplify integration of NXP’s safety products into
applications
• A comprehensible description of all information
relating to FS in a single entity to ensure integrity
of information
Content
• MCU Safety Context
• MCU Safety Concept
• System level hardware assumptions
• System level software assumptions
• FMEDA summary
• Dependent Failures Analysis summary
Safety Manual for Analog Solution
Safety Manual for MCU Solution
Safety Manual for MPC574xP
PUBLIC 45
Safety Manual: Structure
• MCU Safety Context
− Safe states, Fault tolerant time interval
• MCU Safety Concept
− Describes the safety concept of the device (what is implemented and how does it work)
• System level hardware assumptions
− Describes the functions required by external hardware to complement the MCU safety concept (Error out monitor)
• System level software assumptions
− Description of necessary or recommended sw mechanisms for each module (Initial checks, configuration & runtime checks)
• Failure Rates and FMEDA
− Short introduction to FMEDA
• Dependent Failure Analysis
− bic – IEC 61508 Ed. 2.0 part 2, Annex E: Analysis of dependent failures
− Countermeasures against common cause failures on chip level
PUBLIC 46
Safety Support – System Level Application Notes
Design Guidelines for
• Integration of Microcontroller and Analog &
Power Management device
• Explains main individual product Safety
features
• Uses a typical Electrical Power steering
application to explain product alignment
• Covers the ASIL D safety requirements that
are satisfied by using both products:
− MPC5643L requires external measures to
support a system level ASIL D safety level
− MC33907/08 provides those external measures:
External power supply and monitor
External watchdog timer
Error output monitor
PUBLIC 47
Dynamic FMEDA
47
PUBLIC 48
Safety Support – Dynamic FMEDA
Objective
• Tailor FMEDA to match application configuration
• Enables customers, by supporting their system level
architectural choices
Content
• FMEDA methods aligned with functional safety
standards
− SPFM & LFM, PMFH – ISO 26262
− SFF & PFH- IEC 61508 Ed. 2.0
− bic – IEC 61508 Ed. 2.0 part 2, Annex E
• Dynamic FMEDA covers elements with low
application dependency: Clock, Power Supply,
Flash, SRAM, Processing Unit…
Work flow and result
• Customer specifies the failure model (dependent on
Safety Integrity Level) required by their application,
and then confirms the Safety Measures that will be
used or not be used
• A tailored FMEDA is then supplied to customer’s for
their specific application
PUBLIC 49
ISO 26262-5 (Elements and Failure Models)
FMEDA Supply
FMEDA Clock
FMEDA Flash
FMEDA SRAM
Failure Rate
Table
Reference ISO 26262-5:2011
PUBLIC 50
ISO 26262-5 (Elements and Failure Models)
FMEDA
Processing
Unit
Reference ISO 26262-5:2011
PUBLIC 51
Dynamic FMEDA Metrics
• FMEDAs must individually fulfill the
target relative metrics (SPFM, LFM)
• Sum of individual PMHF must fulfill
the absolute target
Power Clock
non-volatile
memory
volatile
memory
Processing
unit
Communication
Digital I/O
Analog I/O
FMEDA FMEDA
FMEDA FMEDA
FMEDA
Failure
rates only
MCU partitioning for analysis individual FMEDAs
SPFM
LFM
PMHF
SPFM
LFM
PMHF
SPFM
LFM
PMHF
SPFM
LFM
PMHF
SPFM
LFM
PMHF
Failure
rates only
PUBLIC 52
Dynamic FMEDA
• Failure Mode, Effect and Diagnostic Analysis
• A systematic way to identify and evaluate failure modes, effects and diagnostic techniques, and to
document the system.
• FMEDA can be tailored to application use-case:
− FMEDA allows adaptation of temperature profile and ASIL level
− FMEDA allows selection of package used
− FMEDA allows selection / de-selection of modules
− FMEDA allows selection / de-selection of diagnostic measures
− FMEDA allows to change particular DCs
− FMEDA can generate a specific (static) “customer FMEDA”
Called “Dynamic FMEDA”
Internal_Version_Core_FMEDA_rev_0_4.xlsm
PUBLIC 53
…
Dynamic FMEDA
Additionally - FMEDA Report• Summarizing the assumptions and the method of the inductive functional safety analysis activities based on the FMEDA
carried out for the MCU
file:///C:/Users/B37424/Documents/Torino/Torino_FMEDA_example.xlsmfile:///C:/Users/B37424/Documents/Torino/Torino_FMEDA_example.xlsm
PUBLIC 54
Safety Plan, Safety
Case & Confirmation
Measures
54
PUBLIC 55
Safety Plan
• Describes the overall approach to functional safety management during the development of the hardware or software components in accordance with ISO 26262 requirements.
• The Safety Plan is based on ISO 26262:2011
• The Safety Plan follows the standard NXP BCaM7 Process, which defines the overall product lifecycle.
• The MCU safety activities are planned and tracked in the as part of standard project plans:
− The safety deliverables are identified by “fs:”
− Key safety activities addressed, including
safety requirements definition and review
safety analysis and review
design implementation and associated testing in verification simulation, silicon validation and qualification
key safety management activities of confirmation reviews, audit activities and assessment.
PUBLIC 56
Key Roles and Responsibilities for ISO 26262
• Functional Safety Architect
− Specification of Functional Safety requirements and performing Functional Safety analysis
• Project Functional Safety Manager
− Project specific set up and maintenance of Functional Safety activities according to organizational Functional Safety standards and product requirements
• Functional Safety Assessor
− Planning and execution of functional safety assessments according to ISO26262 standard and the NXP Functional Safety process
• Organisation Functional Safety Manager
− Implementation of ISO 26262 standard including training into the organization
PUBLIC 57
ISO 26262 Safety Case
• Lists the ISO 26262 Work Products applicable to the development, as well as progressively compiles the deliverables generated during the safety lifecycle which form the safety case along with the safety argument.
• The complete list of information exchanged between NXP (MCU Supplier) and the customer (System developer) is detailed in the ISO 26262 Safety Case, including how the information is exchanged:
− Public Information available via the NXP Website
− Confidential Information available under NDA
− Internal Information available during onsite Audit
• In case NXP enters into a Customer Development Interface Agreement (Customer DIA) for a system, then the Customer DIA takes precedence over the ISO 26262 Safety Case.
PUBLIC 58
ISO26262-10 Table A.8 Checklist
• ISO 26262-10 Annex A.3.7 deals with techniques or measures to detect or avoid systematic failures during MCU design
• It proposes a checklist according to table A.8 to provide evidence that sufficient measures for avoidance of systematic
failures are taken during MCU design
Checklist summary
• Checklist complied with for each NXP design.
• When integrating 3rd party IP, for example from ARM, then major design steps to integrate the 3rd party IP like synthesis, test
insertion, backend etc. is in NXP’s responsibility and NXP provides the data for the checklist.
• 3rd party IP providers give the data for the IP-design part to enable NXP to fill in the checklist
PUBLIC 59
NXP ISO 26262 Confirmation Measures
• NXP performs ISO 26262 Confirmation Reviews (CR), Audit and Assessment as required by ISO 26262 for SEooC
development
• Confirmation Measures (CM) performed depending on ASIL
• All checks executed with independence level I3 by NXP Quality organization
• NXP Assessors certified by SGS-TÜV Saar as Automotive Functional Safety Professional (AFSP)
• NXP CM process certified by SGS-TÜV Saar as ISO 26262 ASIL D
Confirmation
MeasuresASIL A ASIL B ASIL C ASIL D
CR Safety Analysis Yes Yes Yes Yes
CR Safety Plan Yes Yes Yes
CR Safety Case Yes Yes Yes
CR Software Tools Yes Yes
Audit Yes Yes
Assessment Yes YesNote: The following confirmation reviews are not applicable: hazard analysis and risk assessment,
item integration and testing, validation plan & proven in use argument
PUBLIC 60
Autonomous
driving leading to
Fail-operational
systems
SENSE THINK ACT
PUBLIC 61
Functional Safety
Autonomous Driving – SAE Levels
HUMAN MACHINE
FAIL-SAFE DEGRADED MODE FAIL-OPERATIONAL
SYSTEM CONTROL
SYSTEM AVAILABILITY
PUBLIC 62
ConclusionISO 26262 addresses functional safety in
automotive
NXP applies ISO 26262 across Automotive
developments
Faults & Safety Mechanisms are determined for HW
& SW components, NXP safety concepts enable
customers to design their safety systems
ISO 26262 evolving to address the requirements for
safe autonomous vehicle
62
NXP and the NXP logo are trademarks of NXP B.V. All other product or service names are the property of their respective owners. © 2017 NXP B.V.