functional safety development and certification flow
TRANSCRIPT
1
Functional safety Development and certification Flow exida / Texas Instruments Chris O’Brien – exida, CFSE Hoiman Low – TI Safety MCU, FSCAE December / 2014
idae
Topics • exida
– IEC 61508 Safety Lifecycle – Implementing a Compliant New Product Development Process – Functional Safety Management – Documentation Requirements – Certification to Functional Safety Standards
• Texas Instruments – HerculesTM MCU Functional Safety How-To Workshop – Safety Functions, Safety Goals, Safe State, SIL, Failure rate – Safety Critical Elements identification and Diagnostic Requirements – Safety Manual and Diagnostics Selection – Mission Profile and Failure Rate Estimation – SafeTITM Diagnostic Library – SafeTITM Diagnostic Library Compliance Support Package (CSP) certification
support – Summary
2 idae
IEC 61508 Safety Lifecycle
3
“ANALYSIS” Phases
(What does the product need to do?)
“REALIZATION” (NPD to meet the
“What”)
Concept
Overall Scope Definition
Hazard & Risk Analysis
Overall Safety Requirements
Safety Requirements Allocation
Safety-related systems : E/E/PES
Realisation
Overall Installation & Commissioning
Overall Safety Validation
Overall Operation & Maintenance
Decommissioning
Safety-related systems : other Technology
Realisation
External Risk Reduction Facilities
Realisation
Overall Planning
Installation & Commissioning Planning
Validation Planning
Operation & Maintenance Planning
11 10 9
5
4
3
2
1
12
13
14
16
Overall Modification & Retrofit 15
8 7 6
“OPERATION” (How do we keep the system functioning
safely?) Copyright exida 2014
Sensor Logic solver
Final Element
4
Element
element - part of a subsystem comprising a single component or any group of components that performs one or more element safety functions. [IEC 62061, definition 3.2.6, modified] NOTE 1: An element may comprise hardware and/or software. NOTE 2 : A typical element is a sensor, programmable controller or final element
“Product” can mean many things
Copyright exida 2014
5
Systems
Sub-Systems
Elements
Components
1 1-n
1 1-n
1 1-n
The relationship between the items can be expressed as follows: A System is composed of one of more Sub-systems. A Sub-system is composed of one of more Elements. As implied in IEC 61508, it is often useful to include another lower level, a component. In which case we can say that an Element is composed of one or more Components.
Scope Levels
Copyright exida 2014
Safety Lifecycle Requirements
Requirements Must show sufficient design
quality / integrity OPTION 1: Fully Compliant
Process OPTION 2: Proven In Use OPTION 3: Combination
Systematic Capability IEC 61508-2010 Measure (scale of SC 1 to SC 4) of the confidence that the systematic safety integrity of an element meets the requirements of the specified SIL, in respect of the specified element safety function, when the element is applied in accordance with the instructions specified in the compliant item safety manual.
6 Copyright exida 2014
IEC 61508 Development Process
7
Does not show useful details
Copyright exida 2014
Product Development - Phases
8
Phase Process Steps in Phase
Safety Requirements Create and Inspect Product Safety Requirements
Safety Validation Test Planning Create and Inspect Safety Validation Test Plan
System Architecture Design Create and Inspect System Architecture Design Perform System FMEA Create and Inspect Derived Safety Requirements Create and Inspect Integration Test Plan
Hardware Design Perform Detailed Hardware Design Perform Hardware FMEDA Perform Fault Injection Testing
Software Design Create and Inspect Software Architecture Perform Software Criticality Analysis and HAZOP Create and Inspect Detailed Software Design
Implementation Create and Inspect Code Perform Static Analysis Unit Test Code
Integration and Safety Validation Test Execution
Perform Integration Testing Perform Validation Testing Copyright exida 2014
Safety Requirements Phase
9
Development Process Overview
Project Management System Engineering Hardware Development Software Development System Validation
Project Approved
Create and Inspect FSMPlan
Create and InspectSystem SafetyRequirements
Create and InspectDerived Safety
Create and InspectConfiguration
Management Plan
Create and InspectSafety Validation Test
PlanCreate and InspectSystem Architecture
Design
Perform System FMEA
Update and InspectValidation Test Plan
1. Market Requirements • Customer Requirements • Use Cases • SIL Capability, SIL Certification Levels
2. Regulatory Requirements For general purpose products, SIL requirements cannot
come from a specific application hazard analysis Copyright exida 2014
Safety Validation Test Plan Phase
10
Development Process Overview
Project Management System Engineering Hardware Development Software Development System Validation
Project Approved
Create and Inspect FSMPlan
Create and InspectSystem SafetyRequirements
Create and InspectDerived Safety
Create and InspectConfiguration
Management Plan
Create and InspectSafety Validation Test
PlanCreate and InspectSystem Architecture
Design
Perform System FMEA
Update and InspectValidation Test Plan
1. Create and Inspect a “Validation Test Plan” that contains at least high level test objectives.
2. Every requirement must have a test. 3. This step is done to verify that all requirements are
testable. If a test cannot be devised for a particular requirement, then that requirement must be re-written.
Copyright exida 2014
11
System Architecture Design Phase
evelopment Process Overview
Project Management System ngineering Hardware evelopment Software evelopment System Validation
Project Approved
Create and Inspect FSMPlan
Create and InspectSystem SafetyRequirements
Create and InspectDerived SafetyRequirements
Create and InspectConfiguration
Management Plan
Create and InspectSafety Validation Test
PlanCreate and InspectSystem Architecture
Design
Perform System FMEA
Perform DetailedHardware Design
including componentselection
Create and InspectSoftware Architecture
Design
Create and InspectIntegration Test Plan
Update and InspectValidation Test Plan
1. Create and Inspect an overall design by partitioning functions into sub-functions – classical engineering process.
2. Perform System FMEA to verify design integrity. Update requirements and validation test plan.
Copyright exida 2014
System Architecture Steps
12
Create Safety Requirements
System FMEA
System Architecture Design
New Safety Requirements
Draft Validation Test Plan
Change Safety Requirements Requirements Testable?
Design Sufficient?
No
Yes
Allocate Safety Requirements
Yes No
Hardware Design Software Design Steps can be organized and named in any way.
Steps can be iterative – this is normal.
Draft Integration Test Plan Design Testable?
No
Yes Change Design
Copyright exida 2014
Hardware Design Phase
13
Create and InspectDerived SafetyRequirements
esign
Perform System FM A
Perform DetailedHardware Design
including componentselection
Perform HardwareFMEDA
Create and InspectSoftware Architecture
Design
Create and inspectdetailed software design
Create and InspectIntegration Test Plan
Perform SoftwareCriticality Analysis and
HAZOP
Create Code
Create and InspectSafety Manaual
Build HardwarePrototypes
Update and InspectValidation Test Plan
1. Perform detailed hardware design including component selection. Many components are IEC 61508 certified.
2. Perform hardware FMEDA. 3. Build Hardware prototypes – fault injection test.
Copyright exida 2014
Software Design Phase
14
Create and InspectDerived SafetyRequirements
esign
Perform System FM A
Perform DetailedHardware Design
including componentselection
Perform HardwareFMEDA
Create and InspectSoftware Architecture
Design
Create and inspectdetailed software design
Create and InspectIntegration Test Plan
Perform SoftwareCriticality Analysis and
HAZOP
Create Code
Perform Static Analysiswith PC LINT
Create and InspectSafety Manaual
Build HardwarePrototypes
Create DetailedValidation Test
Procedures
Update and InspectValidation Test Plan
1. Create and Inspect Software Architecture – typically block diagram, entity relationship drawings, state diagrams, etc.
2. Perform Software Criticality Analysis and HAZOP 3. Create and Inspect Detail Software Design.
Copyright exida 2014
Implementation Phase
15
Perform HardwareFM A
Create and inspectdetailed software design
Perform SoftwareCriticality Analysis and
HA OP
Create Code
Perform Static Analysiswith PC LINT
Inspect Code
Create and InspectSafety Manaual
Build HardwarePrototypes
Perform IntegrationTesting
Perform ValidationTesting
Create DetailedValidation Test
Procedures
Perform FinalVerification
Unit Test Code
1. Create and Inspect Code 2. Perform Static Analysis on Code 3. Unit Test Code – must be documented and traceable
Copyright exida 2014
Integration and Validation Test
Copyright exida 2014 16
Perform Static Analysiswith PC INT
Inspect Code
Perform IntegrationTesting
Perform ValidationTesting
Create etailedValidation Test
Procedures
Perform FinalVerification
Product Released
Unit Test Code
1. Perform Integration Testing – must be documented with test plans and test results
2. Perform Validation Testing – must be documented with test plans and test results, show traceability to all safety requirements.
Product Development Process Requirements
• This is an example process – other steps and sequences could meet all process requirements of IEC 61508.
• One essential requirement is that all steps required are part of a documented procedure.
• Each step must have sufficient review, testing or other verification technique to ensure design integrity.
17
Safety Integrity Level
SIL 4
SIL 3
SIL 2
SIL 1
Copyright exida 2014
Functional Safety Management Objectives and Requirements • Specify engineering process including each step
with input and output documents. • Control and manage documentation • Specify responsibilities of persons and
organizations • Evaluate competency of those assigned to roles • Evaluate Quality Management of Suppliers • Establish a system to monitor product quality and
safety for the lifetime of the product
18 Copyright exida 2014
Management of Functional Safety
19
1. Concept
2. Overall scope definition
3. Hazard and risk analysis
4. Overall safety requirements
5. Safety requirements allocation
6. Overall operation and maintenance
planning
7. Overall safety
validation planning
8. Overall installation and commissioning
planning
9. SRS E/E/PES
realization
12. Overall installation and commissioning
13. Overall safety validation
14. Overall operation, maintenance, repair
16. Decommissioning or disposal
15. overall modificaton and retrofit
Man
agem
ent o
f Fun
ctio
nal S
afet
y
Doc
umen
tatio
n
Verif
icat
ion
Func
tiona
l Saf
ety
Ass
essm
ent
Back to appropriate overall safety lifecycle
phase
Copyright exida 2014
Defined Engineering Process Objective: • The specific steps required to design and test
a product must be documented in a clear and understandable way.
Requirements: • Input documents for each step are listed. • Output documents for each step are listed. • Design, review and test tasks are specified. • Responsibility for each task is specified.
20 Copyright exida 2014
21
Often a flow chart is used to provide an overview.
Defined Engineering Process
Copyright exida 2014
Documentation Objectives
What needs to be documented? • Any information to effectively perform:
– Each phase of the safety life cycles – The management of functional safety – Verification – Functional Safety Assessment
22 Copyright exida 2014
Typical Documentation
23
Hardware Design Software Design
E/E/PE Integration
Modification
E/E/PE Validation
E/E/PE Safety Requirements Specification Safety Requirements Specification
Functional Safety Management Plan
Verification and Validation Plan/Report User
Installation Manual / Safety Manual
Design Specification
Change Request Database
FMEDA Report Integration Test
Plan / Report Software Module Test Plan/Report
Software Review / Analysis Report
Copyright exida 2014
Documentation
Documentation Requirements: • Title indicating the Scope of the
Contents • Legal entity (e.g. company,
author(s), etc); • Scope and purpose • Revision Index (Version Numbers) • Table of Content and Index • Traceability to functional and SI
requirements • Inputs and outputs
How shall Documentation: • be accurate and concise? • be easy to understand by those
persons having to make use of it? • suit the purpose for which it is
intended? • be accessible and maintainable? • have Titles or Names indicating
the Scope of the Contents? • have a Revision Index (Version
Numbers)? • make it possible to search for
relevant Information?
24 Copyright exida 2014
Process Verification Objective: • evaluate the outputs from a given process step to
ensure correctness and consistency Requirements: • plan verification concurrently with development • verify in accordance with plan • document evidence of satisfactory completion of the
phase being verified – recommend checklist • If problems are found, they are entered onto the
“action item” list and tracked until resolution • Problem issues must be addressed by returning to the
appropriate process step.
25 Copyright exida 2014
26
Recommend checklist at end of each phase completed during or after phase review meeting.
Process Verification
Copyright exida 2014
• New product with no field history: – The new design must have a full hardware
failure analysis.
– The new design must follow the design process requirements of IEC 61508 for the target SIL level.
– A Safety Manual must be created to explain how to use the product at the system level.
27
Random Failure Integrity
Product Systematic Failure Integrity
System Systematic Failure Integrity
Certification Process
Copyright exida 2013
Copyright exida 2014
Accreditation Each Certification Body (CB) operates per a “scheme” and gets accredited by an Accreditation Body (AB). In the USA, ANSI is the AB.
29
Functional Cyber-Security Achilles Level 1-2 ISA Secure Levels 1 – 3
Functional Safety Certification IEC 61508 IEC 61511 IEC 62061 / ISO 13849 IEC / ISO 26262 EN 50271 Other Functional Safety
Copyright exida 2014
Topics • exida
– IEC 61508 Safety Lifecycle – Implementing a Compliant New Product Development Process – Functional Safety Management – Documentation Requirements – Certification to Functional Safety Standards
• Texas Instruments – HerculesTM MCU Functional Safety How-To Workshop – Safety Functions, Safety Goals, Safe State, SIL, Failure rate – Safety Critical Elements identification and Diagnostic Requirements – Safety Manual and Diagnostics Selection – Mission Profile and Failure Rate Estimation – SafeTITM Diagnostic Library – SafeTITM Diagnostic Library Compliance Support Package (CSP) certification
support – Summary
30 idae
Applying Functional Safety Standards
31
HerculesTM
Architecture (FMEDA)
SafeTI™ design packages help meet functional safety requirements while
managing both systematic and random failures.
Systematic Failures
Tools
Safety Plan
Documentation
Config Management
Change Management
V&V
Personnel Competence
Certification
SIL - 1/2/3/4
Functional Safety
Safety Life Cycle
Risk reduction
Software
Random Failures
Diagnostics
Architectural Metric
Failure Rate
CSP = Compliance Support Package
Development Process
Workshop will address: • How to manage MCU hardware
random failures • How to estimate failure rate vs SIL
requirements • Software support
32
Development Process
Software
Functional Safety Certification
Hardware
MCU Hardware
Safety Metric MCU Software
Drivers, Library Tool
MCU Development
Process
System
Show me evidence
33
SIL Determination (SIL - 1/2/3/4)
Safety Function Definition
SW Safety Requirements
Allocation of Safety Requirements
Hazard & Risk Analysis
HW Safety Requirements
(SFF, PFH)
Process Safety Requirements
IEC 61508 Hazard/Risk Analysis & SIL determination
34
Safety Function / Safe State
Sensor Actuator MCU
Hazard analysis -> Safety Function & Safe State Safety Function: function to be implemented by an E/E/PE safety-related system or other risk reduction measures, that is intended to achieve or maintain a safe state for the ECU, in respect of a specific hazardous event Safe State: State of the ECU when safety is achieved
35
Safety Function / Safe State
Hazard: High gas flow pressure Safety Function: Monitor the pressure of gas flow. If gas flow pressure exceeds a fixed limit, shut off the gas flow valve. Safe State: If a dangerous fault is detected in the system, shut off the gas flow
Sensor Actuator MCU
36
Risk Analysis / Safety Integrity Level
Risk Analysis determines the performance requirement of the safety function, i.e. SIL level and how much risk reduction? Safety Integrity Level (SIL 1/2/3/4) is determined by the consequence and the frequency of hazardous event. The higher the SIL level, the higher the risk reduction requirements
Sensor Actuator MCU
37
Safety Integrity Level • Safety Integrity Level is characterized by SFF and PFDAVG or PFH
• Single Failure Fraction (SFF)
• Probability of Fail on Demand Average (PFDAVG)
• Probability of Fail per Hour (PFH)
• SFF = (λSAFE + λDANGEROUS-DETECTED) / (λSAFE + λDANGEROUS-DETECTED+ λDANGEROUS-UNDETECTED)
• PFH ≈ 1 / λDANGEROUS-UNDETECTED
38
Safety Integrity Level
SIL SFF (HFT=0) PFH (FIT)
SIL1 0% … <60% <10000
SIL2 60% … <90% <1000
SIL3 90% … <99% <100
1 FIT = 1 failure in 1E9 hours
Type B products are complex products in which all failure modes are not known. Most semiconductors are considered Type B.
HFT = Hardware Fault Tolerance where 0=No redundancy
39
MCU Failure Mode and Failure Rate
• Source of permanent component failure rate data: • MILHDBK 217F • SN29500 • IEC/TR 62380 • Supplier reliability data • …
• TI uses IEC/TR 62380 where # of transistors, # of memory bits, temperature and package effect can be modeled.
• Failure rate is commonly expressed in FIT (Failure In Time) • 1 FIT = 1 failure in 1E9 hours.
• Permanent random failures: • Tox integrity, Short, Open, Stuck At, Drift ….
• Transient random failures: • Cosmic Rays, EMC
• Failure rate data source is TI experiments in Los Alamos lab and TI lab
40
CPU failure rate (λCPU)
Failure rate analysis λCPU
λSAFE, λDD, λDU
Apply CPU Diagnostics
MCU Failure Rate Partition / Estimation
SRAM failure rate (λSRAM)
Failure rate analysis λSRAM
λSAFE, λDD, λDU
Apply SRAM Diagnostics
Flash failure rate (λFlash)
Failure rate analysis λFlash
λSAFE, λDD, λDU
Apply Flash Diagnostics
MCU failure rate (λMCU)
Apply diagnostics to detect dangerous faults until appropriate SIL metrics (SFF, PFH) are met λSAFE - Safe, λDD – Dangerous Detected, λDU – Dangerous Undetected
Application Example
41
Hercules MCU Pre Drivers
H Bridge Drivers
BLDC
Motor
Quadrature Encoder
Pre Drivers
Voltage Regulator
5-16MHz Clock Crystal
DCAN1
eQEP
ePWM1
NHET1
OSCIN OSCOUT 1.2v 3.3v 5v
Warning Lamp GIO
ePWM2
ePWM3
Motor Torque
Command from
Remote Host
Motor Position Feedback
nPORRST
Sys
tem
Res
et
Safety Function Input (MCU)
Receive motor torque command from remote host (CAN)
Read current motor position (feedback) via quadrature decoder
(eQEP)
Safety Function Processing (MCU)
Calculate necessary output commands to motor based on
desired torque and current position
Safety Function Actuation (MCU)
Drive three phase PWMs to actuate motor (ePWM)
Safe State (MCU)
1. Disable motor driver relay (NHET)
2. Indicate fault to system via warning lamp (GIO)
Safety Goal: The motor shall deliver torque as commanded by the external host.
42
MCU Safety Critical Elements per Safety Function
SPI2
DMA POM HTU1 FTU HTU2
Switched Central Resource Switched Central Resource
CRC
High Freq. Central Resource
Peripheral Central Resource Bridge
Switched Central Resource
MibADC1 MibADC2 I2CN2HET1 FlexRayGION2HET2
64 KB Flashfor EEPROM
Emulationwith ECC
EMAC OHCI
Main Cross Bar: Arbitration and Prioritization Control
Dual Cortex-R4FCPUs in Lockstep
1.25MFlashwithECC
64K64K64K
192KRAMwithECC
EMAC Slaves
MDIO
MII
EMIF
USB
Device
Host
DCAN1System
ESM
SCI
LIN
MibSPI5
SPI4
MibSPI3
MibSPI1
DCAN3
DCAN2
IOMM
PMM
VIM
RTI
DCC1
DCC2
PBIST
Fuse Farm
CCMR4
LBIST
Switched Central Resource
eQEP 1,2
eCAP1,2
ePWM1..7
• Safety Critical Elements are elements within MCU the implement the safety function
• Diagnostics are necessary to detect safety related failures
• Sufficient diagnostics coverage (DC) is needed to meet required IEC 61508 HW metrics per SIL level
• In this example, safety critical elements are: CPU, Flash, SRAM, Interconnect, eQEP, eCAP, ePWM, System, ESM… I2C
43
MCU Safety Diagnostic Requirements per Safety Function
Safety Requirement ID Satisfies Assumed Safety Diagnostic Requirement SIL SFR_1 SF_1 MCU safety related functional input shall be considered safety critical SIL 3 SFR_1.1 SFR_1 DCAN1 shall be considered safety critical SIL 3 SFR_1.2 SFR_1 eQEP1 shall be considered safety critical SIL 3 SFR_2 SF_1 MCU safety related functional output shall be considered safety critical SIL 3 SFR_2.1 SFR_2 ePWM1 shall be considered safety critical SIL 3 SFR_2.2 SFR_2 ePWM2 shall be considered safety critical SIL 3 SFR_2.3 SFR_2 ePWM3 shall be considered safety critical SIL 3 SFR_3 SF_1 MCU safety related processing shall be considered safety critical SIL 3 SFR_3.1 SFR_3 Cortex R4F CPU shall be considered safety critical SIL 3 SFR_3.2 SFR_3 TCM SRAM as needed to support the application shall be considered safety critical SIL 3 SFR_3.3 SFR_3 TCM Flash as needed to support the application shall be considered safety critical SIL 3 SFR_3.4 SFR_3 L2/L3 interconnect as needed to support the application shall be considered safety critical SIL 3 SFR_3.5 SFR_3 VIM shall be considered safety critical SIL 3
SFR_4 SF_1 MCU functions necessary to support safety related input, processing, and output shall be considered safety critical SIL 3 SFR_4.1 SFR_4 Power supply shall be considered safety critical SIL 3 SFR_4.2 SFR_4 PMM shall be considered safety critical SIL 3 SFR_4.3 SFR_4 Clocking subsystem shall be considered safety critical SIL 3 SFR_4.4 SFR_4 Reset logic shall be considered safety critical SIL 3 SFR_4.5 SFR_4 I/O multiplexing (IOMM) shall be considered safety critical SIL 3 SFR_4.6 SFR_4 RTI shall be considered safety critical SIL 3 SFR_4.7 SFR_4 System control module shall be considered safety critical SIL 3 SFR_4.8 SFR_4 ESM shall be considered safety critical SIL 3 SFR_4.9 SFR_4 Fuse Farm shall be considered safety critical SIL 3 SFR_4.10 SFR_4 OTP configuration shall be considered safety critical SIL 3 SFR_5 SF_1 MCU functions necessary to support the safe state shall be considered safety critical SIL 3 SFR_5.1 SFR_5 NHET1 shall be considered safety critical SIL 3 SFR_5.2 SFR_5 GIO shall be considered safety critical SIL 3
44
How to implement Diagnostics?
• An overview of the safety architecture for management of random failures
• The details of architecture partitions, implemented safety mechanisms, and recommended usage
• Failure modes and failure rates
HerculesTM Safety Manual
45
HerculesTM MCU safety features Safe Island Hardware diagnostics
Blended HW diagnostics
Non Safety Critical Functions
Lockstep CPU & Lockstep Interrupt
Fault Detection
CPU Self Test Controller requires little S/W overhead
Physical design optimized to reduce
probability of common cause failure
PBIST/LBIST OSC PLL
POR
CRC RTI/DWWD
ESM
Enhanced System Bus and lockstep Vectored Interrupt Module
DMA
Memory Flash
w/ ECC
Embedded Trace
RAM w/ ECC
Power, Clock, & Safety
Memory Interface JTAG Debug Calibration
Serial Interfaces
Network Interfaces
Dual ADC
Cores Available
Dual High-end Timers
Available
GIO
Flash EEPROM w/ ECC
Compare Module for Fault Detection
ECC or Parity on select Peripheral, DMA and Interrupt controller RAMS
Parity or CRC in Serial and Network
Communication Peripherals
IO Loop Back, ADC Self Test, …
Dual ADC Cores with shared channels
External Memory
ARM® Cortex® R w/ MPU
ECC for flash / RAM evaluated inside the
Cortex R
Memory Protection
Unit Memory BIST on all
RAMS for fast memory test
Error Signaling Module w/ External
Error Pin
On-Chip Clock and Voltage Monitoring
Protected Bus and lockstep Interrupt
Manager
AR
M®
Cortex
® R
w/ M
PU
Lockstep CPU
Bold items are introduced with the new Cortex®-R5 devices
Random
46
SIL Determination (SIL - 1/2/3/4)
Safety Function Definition
SW Safety Requirements
Allocation of Safety Requirements
Hazard & Risk Analysis
HW Safety Requirements
(SFF, PFH)
Process Safety Requirements
Estimate SFF / PFH per Safety Function Now we have a safety function and SIL requirement,
→ How to estimate the SFF / PFH to determine if SIL requirement can be met?
47
Estimate MCU SFF / PFH per Safety Function Use Hercules MCU Detailed Safety Analysis Report & FMEDA worksheet
Evaluate IEC61508 Failure Rate Summary
Apply Diagnostics to Used Modules per
Safety Function
Set Up Mission Profile of System
SFF/PFH met?
N
Y
Done
What is the total failure rate per used
conditions?
What Self-Test should be implemented?
48
Detailed Safety Analysis Report & FMEDA worksheet Detailed Safety Analysis Report • Assumptions of use applied in calculation of safety metrics
• Summary of IEC 61508 or ISO 26262 standard safety metrics at the MCU component level
• A fault model used to estimate device failure rates and an example of customizing this model for use with the example application.
• FMEDA with details to the sub-module level of the MCU, that enables calculation of safety metrics based on customized application of diagnostics
Available under NDA
* FMEDA Developed with Yogitech
49
IEC61508 HW Metrics Calculation Failure Rate
Multiple Ways for Random failure rate estimation: • MIL-HDBK-217F, "Military Handbook - Reliability Prediction of
Electronic Equipment” • Siemens Norm SN29500:2010, "Failure Rates of
Components” • Supplier reliability data from similar products already in
production and deployed under similar operating conditions • IEC/TR 62380:2004, "Reliability Data Handbook - Universal
Model for Reliability Prediction of Electronics, PCBs, and Equipment”
• TI has selected to use IEC/TR 62380 because it is more aligned to semiconductor physics models
• Failure rate is measured in FIT where 1 FIT is 1 fail in 109 operating hours
Random Hardware
Failure
Die (silicon) Permanent
Die (silicon) Transient
Package Permanent
50
IEC61508 HW Metrics Calculation Failure Rate / Mission Profiles
Random Hardware
Failure
Die (silicon) Permanent
Die (silicon) Transient
Package Permanent
51
IEC61508 HW Metrics Calculation Automotive Motor Control Mission Profiles
• Automotive Mission Profile in IEC/TR 62380 (FMEDA worksheet default): – 10 years service with 3 phases per day – night, day, not used
• 2 night trips per day, 4 day trips per day, 30 days shut down – 3 temperature phases
• Engine cold, Engine warm, Engine hot – On/Off ratio: 0.058 / 0.942
Automotive Mission Profile: Total raw die permanent FIT: 9.48
Based on RM48x v1.0 FMEDA worksheet
Customer input for failure rate estimation
Package Used TI PBGA
Customer input for transient fault estimation Application specific Flux Factor coeff. based on Jedec JESD89A 1
Maximum power dissipation Application specific power dissipation in Watts 1.04 (1.04W is based on maximum datasheet value)
Assumed Lifetime in years 10
Confidence Level Desired confidence level of FIT rates 70%
Operational Profile from IEC/TR 62380:2004 Temp1 Temp2 Temp3 Ratios on/off 2 night starts 4 day light
starts Non used
vehicle
(tac)1 °C τ1 (tac)2 °C τ2 (tac)3 °C τ3 Τon Τoff n1 ΔT1 °C n2 ΔT2 n3 ΔT3
Profile 32 0.02 60 0.015 85 0.023 0.058 0.942 670 ΔTj/3+55 1340 ΔTj/3+45 30 10
52
FMEDA worksheet – Product Function Tailoring
• Allow customization of failure rate estimation • Include only MCU modules used by
application • Include actual Flash and SRAM
memory size used
53
FMEDA worksheet – Safety Mechanisms Tailoring
• Allow customization of diagnostics selection.
• For example, CPU lock-step compare and boot time LBIST are used, while periodic LBIST is not used.
54
FMEDA worksheet – Package/Pin Tailoring
Allow customer to adjust the number of pins used by module in its application • Example: 31 NHET1 pins are
available, if only 20 pins are used, change to 20
Allow customer to input pin-level application diagnostic with its own diagnostic coverage number
55
FMEDA worksheet – Metrics Summary / Details Summary of IEC 61508 Metrics Examples – Permanent/Transient & Die/Package:
Details of IEC 61508 Metrics:
• For Permanent and Transient faults
• By modules (CPU, Flash, SRAM, DCAN, ADC…)
Numbers are normalized to Die Permanent Total RAW FIT
Based on RM48x v1.0 FMEDA worksheet
56
HerculesTM and SafeTITM Software and Tool Packages
Hercules Software and Tools Hercules standard software and tools packages
Assists in software development on Hercules Safety MCUs Provides the actual software/tool with source code, GUI, … User guides, datasheets, release notes, … Regular updates for enhancements, fixes, …
Free / click wrap license agreement
SafeTI Compliance Support Package
SafeTI Tool Qualification Kit
SafeTI software documentation and testing Assists customer to comply to functional safety standards Safety Requirements Document, Code Review and Coverage
Reports, Unit Test Results, Software Safety Manual, …. Unit Test capability using LDRAunit (if applicable)
See Pricing / signed license agreement
SafeTI tool documentation and qualification Assists customer to qualify tool to functional safety standards Tool Classification Report, Tool Qualification Plan and Report,
Tool Safety Manual, … TI Test Automation Unit or LDRAunit (if applicable)
See pricing / signed license agreement
FREE!!
56
57
HerculesTM Software and Tool Packages
* - these are provided for software that is configurable by user (ie; HALCoGen and CCS Compiler)
Standard Package Compliance Support Package Tool Qualification Kit
Code in source form (see note) Software Safety Requirements Document Tool Safety Requirements Document
GUI for user configuration (if applicable) Software Safety Architecture Document Tool Safety Architecture Document
Software/Tool user guide Code Review Report (w/ MISRA-C) Code Review Report (w/ MISRA-C)
Data sheet Quality Review Report Quality Review Report
Release notes Dynamic Coverage Analysis Report Dynamic Coverage Analysis Report
Unit Test Regression Report Unit Test Regression Report
Traceability report Traceability report
Test Results Report Test Results Report
Software Safety Manual Tool Safety Manual
Safety Assessment Report (Internal) Safety Assessment Report (Internal)
Compliance Level Tool
Templates for Compliance Documentation
Executable Test Cases* Executable Test Cases*
Click Wrap License Signed License Agreement Signed License Agreement
58
ISO 26262 and IEC61508 Standards TI Work Products TI SW Product Lifecycle
ISO 26262 Clause IEC 61508 Clause ISO 26262 Work products IEC61508 Work products Customer Deliverable
Gen
eric
Inpu
ts- (
Can
mod
ify d
urin
g pr
ojec
t tai
lorin
g)
CP
1-P
roje
ct C
omm
issi
onin
g
CP
2- S
afet
y R
equi
rem
ents
& P
lann
ing
CP
3A- D
esig
n &
Impl
emen
tatio
n
CP
3B- U
nit T
estin
g &
Inte
grat
ion
Test
ing
CP
4- S
afet
y R
equi
rem
ents
Ver
ifica
tion
& R
elea
se
CP
5- P
roje
ct C
losu
re
6 Specification of software safety requirements
7.2.2 Software safety requirements specification
6.5.1 Software safety requirements specification
Software safety requirements specification
Software Requirements Document
X
Bi-Directional Traceability Forward and Backward Traceability at all stages
Verification Reports Forward and backward traceability
Traceability matrix X
7 Software architectural design
7.4.3 Requirements for SW Architecture Design development
7.5.1 Software architectural design specification
software architecture design;
SW Architecture Spec X
9 Software unit testing 7.4.5 Detailed design and development (individual software module design):
9.5.3 Software verification report (refined)
SW Module Test Report Unit Test & Static Analysis Report, Dynamic Coverage Analysis Report, Test Manager Report
X
10 Software integration and testing
7.4.8 Software integration testing:
10.5.3 Embedded software verified and tested integrated programmable electronics
SW User Guide, Software Safety Manual, Data sheet
X X
11 Verification of software safety requirements
7.7.2 Software aspects of system safety validation
11.5.3 Software verification report (refined)
software safety validation results; validated software
Safety Test Report X
7.4.9- Safety Manual Safety Manual SW Manual X
6.4.9 Safety Assessment Software functional 8 safety assessment
Functional Safety Assessment Plan Functional Safety Assessment Report
software functional safety assessment plan software functional safety assessment report
Functional Safety Assessment Plan in Safety, Plan, Functional Safety Assessment Report
X X X X X X X
Software Compliance Support Package Deliverables
Hercules Product & Process Certification Hercules RM46 and TMS570LS12x/11x TUEV SUD Certification
• First devices certified by Exida for IEC 61508 SIL3 use in 2011
• TÜV-SÜD certified the SafeTI Hardware functional safety development process in 2013 for: IEC 61508 SIL-3
ISO 26262 ASIl-D
• Hercules MCUs assessed for IEC 61508 SIL-3 and ISO 26262 ASIL D: Hercules Safety Architecture
Device
• TÜV-SÜD concept assessment for ISO 13849: Lockstep + Safety Companion concept
Hercules MCU + TPS 65381
• SafeTI Software functional safety development process certification for: IEC 61508 SIL-3
ISO 26262 ASIL-D
√
√
√
Jan 2015
√
13849
61508, 26262
61508
√
59
60
HerculesTM MCUs: Accelerating Safety Products to Market
Unique Tools for Safety
Development
Certified Safety
Hardware Architecture
ARM based Lockstep MCU
supplier
Comprehensive Portfolio
Complementary Analog
Production Quality Safety
Software
Broad Eco-system
Hercules Safety MCU
TM
• Software • Development Tools • Consulting & Training
• Ease development • Aid certification
• Usable by customer • Certification Ready • ISO 26262, IEC 61508
compliant
• Pin & SW Compatible • Safety Chipset • SafeTI Program
• Non-proprietary • Market accepted • Respected heritage
• Pre-approved for ISO 26262, IEC 61508
• Safety Analysis Report with FMEDA, FIT
61
Thank You
Contact Information: Chris O’Brien:[email protected]
Hoiman Low: [email protected]
idae