Transcript TI Safety MCUs in Industrial

Functional safety Development and
certification Flow
exida / Texas Instruments
Chris O’Brien – exida, CFSE
Hoiman Low – TI Safety MCU, FSCAE
February/2015
e ida
1
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
e ida
2
IEC 61508 Safety Lifecycle
1
Concept
2
Overall Scope
Definition
3
Hazard & Risk
Analysis
4
Overall Safety
Requirements
5
Safety Requirements
Allocation
Overall Planning
6
Operation &
Maintenance 7
Planning
Validation
8
Planning
Installation &
Commissioning
Planning
9
“ANALYSIS”
Phases
(What does the product
need to do?)
Safety-related
systems :
E/E/PES
Realisation
Safety-related
systems : other
10 Technology
Realisation
12
Overall Installation
& Commissioning
13
Overall Safety
Validation
14
Overall Operation &
Maintenance
External Risk
Reduction
11 Facilities
Realisation
“REALIZATION”
(NPD to meet the
“What”)
15
Overall Modification
& Retrofit
16 Decommissioning
Copyright exida 2014
“OPERATION”
(How do we keep the
system functioning
3
safely?)
“Product” can mean many things
Element
Sensor
Logic
solver
Final
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
Copyright exida 2014
4
Scope Levels
Systems
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.
Copyright exida 2014
1
1-n
SubSystems
1
1-n
Elements
1
1-n
Components
5
Safety Lifecycle Requirements
Requirements




Systematic Capability
Must show sufficient design
quality / integrity
OPTION 1: Fully Compliant
Process
OPTION 2: Proven In Use
OPTION 3: Combination
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.
Copyright exida 2014
6
IEC 61508 Development Process
Does not show
useful details
Copyright exida 2014
7
Product Development - Phases
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
8
Safety Requirements Phase
Development Process Overview
Project Management
Project Approved
Create and Inspect FSM
Plan
System Engineering
Hardware Development
Software Development
System Validation
Create and Inspect
System Safety
Requirements
Create and Inspect
Configuration
Management Plan
Create and Inspect
System Architecture
Design
Create and Inspect
Safety Validation Test
Plan
1. Market Requirements
•
•
•
Perform System FMEA
Customer Requirements
Use Cases
SIL Capability, SIL Certification Levels
Update and Inspect
Validation Test Plan
Create and Inspect
Derived Safety
Requirements
2. Regulatory Requirements
Perform Detailed
Hardware Design
including component
selection
Create and Inspect
Software Architecture
Design
For general purpose products, SIL requirements cannot
come from a specific application hazard analysis
Create and Inspect
Copyright exida Integration
2014 Test Plan
9
Safety Validation Test Plan Phase
Development Process Overview
Project Management
Project Approved
Create and Inspect FSM
Plan
System Engineering
Hardware Development
Software Development
System Validation
Create and Inspect
System Safety
Requirements
Create and Inspect
Configuration
Management Plan
Create and Inspect
System Architecture
Design
Create and Inspect
Safety Validation 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.
Perform System FMEA
Update and Inspect
Validation Test Plan
Create and Inspect
Derived Safety
Requirements
Perform Detailed
Hardware Design
including component
selection
Create and Inspect
Software Architecture
Design
Create and Inspect
Copyright exida Integration
2014 Test Plan
10
Development Process Overview
Project Management
Project Approved
Create and Inspect FSM
Plan
System Architecture Design
Phase
System Engineering
Hardware Development
Software Development
System Validation
Create and Inspect
System Safety
Requirements
Create and Inspect
Configuration
Management Plan
Create and Inspect
System Architecture
Design
Create and Inspect
Safety Validation Test
Plan
Perform System FMEA
Update and Inspect
Validation Test Plan
Create and Inspect
Derived Safety
Requirements
Perform Detailed
Hardware Design
including component
selection
Create and Inspect
Software Architecture
Design
1. Create and Inspect an overall design by partitioning functions into
sub-functions – classical engineeringCreate
process.
and Inspect
Integration Test Plan
2. Perform System FMEA to verify design integrity. Update
Perform Software
requirements and validation Perform
testHardware
plan.
FMEDA
Copyright exida 2014
Criticality Analysis and
HAZOP
11
System Architecture Steps
Steps can be iterative – this is normal.
Create Safety Requirements
Draft Validation Test Plan
Change Safety Requirements
Requirements
Testable?
No
Yes
System Architecture Design
Design Testable?
Change Design
No
Draft Integration Test Plan
Yes
New Safety Requirements
No
System FMEA
Yes
Allocate Safety Requirements
Hardware Design
Copyright exida 2014
Design
Sufficient?
Software Design
Steps can be organized and named in any way.
12
Hardware Design Phase
Perform System FMEA
Update and Inspect
Validation Test Plan
Create and Inspect
Derived Safety
Requirements
Perform Detailed
Hardware Design
including component
selection
Create and Inspect
Software Architecture
Design
Create and Inspect
Integration Test Plan
Perform Hardware
FMEDA
Build Hardware
Prototypes
Perform Software
Criticality Analysis and
HAZOP
Create and inspect
detailed software design
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.
Create and Inspect
Safety Manaual
Create Code
Perform Static Analysis
with PC LINT
Copyright exida 2014
Create Detailed
Validation Test
Procedures
13
Inspect Code
Software Design Phase
Perform System FMEA
Update and Inspect
Validation Test Plan
Create and Inspect
Derived Safety
Requirements
Perform Detailed
Hardware Design
including component
selection
Create and Inspect
Software Architecture
Design
Create and Inspect
Integration Test Plan
Perform Hardware
FMEDA
Build Hardware
Prototypes
Create and Inspect
Safety Manaual
Perform Software
Criticality Analysis and
HAZOP
Create and inspect
detailed software design
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.
Create Code
Perform Static Analysis
with PC LINT
Copyright exida 2014
Inspect Code
Create Detailed
Validation Test
Procedures
14
Perform Software
Criticality Analysis and
HAZOP
Perform Hardware
FMEDA
Implementation Phase
Build Hardware
Prototypes
Create and inspect
detailed software design
Create and Inspect
Safety Manaual
Create Code
Perform Static Analysis
with PC LINT
Create Detailed
Validation Test
Procedures
Inspect Code
Unit Test Code
Perform Final
Verification
Perform Integration
Testing
Perform Validation
Testing
1. Create and Inspect Code
2. Perform Static Analysis on Code
3. Unit Test Code – must be documented and traceable
Product Released
Copyright exida 2014
15
Create Code
Perform Static Analysis
with PC LINT
Create Detailed
Validation Test
Procedures
Integration and Validation Test
Inspect Code
Unit Test Code
Perform Final
Verification
Perform Integration
Testing
Perform Validation
Testing
Product Released
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.
Copyright exida 2014
16
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.
Copyright exida 2014
Safety Integrity
Level
SIL 4
SIL 3
SIL 2
SIL 1
17
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
Copyright exida 2014
18
Management of Functional Safety
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
12. Overall installation
and commissioning
9. SRS
E/E/PES
realization
Back to appropriate
overall safety lifecycle
phase
13. Overall safety
validation
14. Overall operation,
maintenance, repair
Functional Safety Assessment
2. Overall scope
definition
Verification
Management of Functional Safety
Documentation
1. Concept
15. overall modificaton
and retrofit
16. Decommissioning
or disposal
Copyright exida 2014
19
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.
Copyright exida 2014
20
Defined Engineering Process
Often a flow
chart is used to
provide an
overview.
Copyright exida 2014
21
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
Copyright exida 2014
22
Typical Documentation
Functional
Safety
Management
Plan
E/E/PE Safety Requirements Specification
Hardware
Design
DesignSpecification
FMEDA
Report
Change
Request
Database
Software
E/E/PE Integration
Integration Test
Plan / Report
E/E/PE Validation
Verification
and Validation
Plan/Report
Modification
Copyright exida 2014
Safety
Requirements
Specification
Software
Design
Review /
Analysis Report
Software
Module Test
Plan/Report
User
Installation
Manual /
Safety Manual
23
Documentation
Documentation Requirements: How shall Documentation:
•
•
•
•
•
•
•
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
•
•
•
•
•
•
•
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?
Copyright exida 2014
24
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.
Copyright exida 2014
25
Process Verification
Recommend checklist at end of each phase completed
during or after phase review meeting.
Copyright exida 2014
26
Certification Process
• New product with no field history:
Random Failure
Integrity
– The new design must have a full hardware
failure analysis.
Product Systematic Failure
Integrity
– The new design must follow the design
process requirements of IEC 61508 for the
target SIL level.
System Systematic Failure
Integrity
– A Safety Manual must be created to explain
how to use the product at the system level.
Copyright exida 2013
27
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.
 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
29
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
e ida
30
Applying Functional Safety Standards
Functional Safety
SafeTI™ design packages help meet
functional safety requirements while
managing both systematic and
random failures.
Risk reduction
Safety Life Cycle
Development Process
SIL - 1/2/3/4
Systematic Failures
Safety Plan
Software
Documentation
Tools
Config Management
Workshop will address:
•
•
•
How to manage MCU hardware
random failures
How to estimate failure rate vs SIL
requirements
Software support
Random Failures
Change Management
Diagnostics
V&V
Architectural Metric
Personnel Competence
Failure Rate
Certification
HerculesTM
Architecture
(FMEDA)
CSP = Compliance Support Package
31
Functional Safety Certification
System
Development
Process
MCU
Development
Process
Software
MCU
Software
Drivers, Library
Tool
Hardware
MCU
Hardware
Safety Metric
Show me evidence
32
IEC 61508
Hazard/Risk Analysis & SIL determination
Hazard & Risk
Analysis
Safety Function
Definition
SIL Determination
(SIL - 1/2/3/4)
Allocation of Safety
Requirements
HW Safety
Requirements
(SFF, PFH)
SW Safety
Requirements
Process Safety
Requirements
33
Safety Function / Safe State
Hazard analysis -> Safety Function &
Safe State
Safety Function: function to be
implemented by an E/E/PE safetyrelated 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
Sensor
MCU
Actuator
Safe State: State of the ECU when
safety is achieved
34
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.
Sensor
MCU
Actuator
Safe State:
If a dangerous fault is detected in the
system, shut off the gas flow
35
Risk Analysis / Safety Integrity Level
Risk Analysis determines the
performance requirement of the
safety function, i.e. SIL level and
how much risk reduction?
Sensor
MCU
Actuator
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
36
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
37
Safety Integrity Level
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
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
38
MCU Failure Mode and Failure Rate
• Permanent random failures:
• Tox integrity, Short, Open, Stuck At, Drift ….
• 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.
• Transient random failures:
• Cosmic Rays, EMC
• Failure rate data source is TI experiments in
Los Alamos lab and TI lab
39
MCU Failure Rate Partition / Estimation
MCU failure rate
(λMCU)
SRAM failure rate
(λSRAM)
CPU failure rate
(λCPU)
Flash failure rate
(λFlash)
Apply SRAM
Diagnostics
Apply CPU
Diagnostics
Apply Flash
Diagnostics
Failure rate analysis
λSRAM
λSAFE, λDD, λDU
Failure rate analysis
λCPU
λSAFE, λDD, λDU
Failure rate analysis
λFlash
λSAFE, λDD, λDU
Apply diagnostics to detect dangerous faults until appropriate SIL metrics (SFF, PFH) are met
λSAFE - Safe, λDD – Dangerous Detected, λDU – Dangerous Undetected
40
Application Example
Voltage
Regulator
Motor
Torque
Command
from
Remote
Host
1.2v 5v 3.3v
Pre Drivers
OSCIN OSCOUT
nPORRST
DCAN1
Safe State (MCU)
Hercules MCU
Safety Function Input (MCU)
Receive motor torque command
from remote host (CAN)
Safety Function Processing
(MCU)
Calculate necessary output
commands to motor based on
desired torque and current
position
Read current motor position
(feedback) via quadrature decoder
(eQEP)
Quadrature
Encoder
5-16MHz
Clock Crystal
System Reset
Safety Goal: The motor shall deliver torque as commanded by the external host.
eQEP
GIO
Warning
Lamp
1. Disable motor driver relay
(NHET)
2. Indicate fault to system via
warning lamp (GIO)
Safety Function Actuation
(MCU)
ePWM1
ePWM2
Pre Drivers
ePWM3
NHET1
H Bridge
Drivers
Drive three phase PWMs to
actuate motor (ePWM)
BLD
C
Motor
Motor Position Feedback
41
MCU Safety Critical Elements per Safety Function
1.25M
Flash
with
ECC
64K
64K
64K
DMA
Dual Cortex-R4F
CPUs in Lockstep
HTU1
POM
FTU
EMAC
HTU2
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
OHCI
Switched Central Resource Switched Central Resource Switched Central Resource
Main Cross Bar: Arbitration and Prioritization Control
CRC
•
192K
RAM
with
ECC
Switched Central Resource
Peripheral Central Resource Bridge
High Freq. Central Resource
64 KB Flash
for EEPROM
Emulation
with ECC
eQEP
1,2
EMAC Slaves
USB
MDIO
eCAP
1,2
System
DCAN1
ESM
DCAN2
IOMM
DCAN3
PMM
MibSPI1
MII
VIM
Host
ePWM
1..7
RTI
SPI2
PBIST
LBIST
MibSPI3
CCMR4
EMIF
Fuse
Farm
SPI4
Device
DCC1
DCC2
MibSPI5
LIN
MibADC1
MibADC2
N2HET1
N2HET2
GIO
FlexRay
I2C
SCI
42
MCU Safety Diagnostic Requirements
per Safety Function
Safety Requirement ID
SFR_1
SFR_1.1
SFR_1.2
SFR_2
SFR_2.1
SFR_2.2
SFR_2.3
SFR_3
SFR_3.1
SFR_3.2
SFR_3.3
SFR_3.4
SFR_3.5
Satisfies
SF_1
SFR_1
SFR_1
SF_1
SFR_2
SFR_2
SFR_2
SF_1
SFR_3
SFR_3
SFR_3
SFR_3
SFR_3
Assumed Safety Diagnostic Requirement
MCU safety related functional input shall be considered safety critical
DCAN1 shall be considered safety critical
eQEP1 shall be considered safety critical
MCU safety related functional output shall be considered safety critical
ePWM1 shall be considered safety critical
ePWM2 shall be considered safety critical
ePWM3 shall be considered safety critical
MCU safety related processing shall be considered safety critical
Cortex R4F CPU shall be considered safety critical
TCM SRAM as needed to support the application shall be considered safety critical
TCM Flash as needed to support the application shall be considered safety critical
L2/L3 interconnect as needed to support the application shall be considered safety critical
VIM shall be considered safety critical
SIL
SIL 3
SIL 3
SIL 3
SIL 3
SIL 3
SIL 3
SIL 3
SIL 3
SIL 3
SIL 3
SIL 3
SIL 3
SIL 3
SFR_4
SFR_4.1
SFR_4.2
SFR_4.3
SFR_4.4
SFR_4.5
SFR_4.6
SFR_4.7
SFR_4.8
SFR_4.9
SFR_4.10
SFR_5
SFR_5.1
SFR_5.2
SF_1
SFR_4
SFR_4
SFR_4
SFR_4
SFR_4
SFR_4
SFR_4
SFR_4
SFR_4
SFR_4
SF_1
SFR_5
SFR_5
MCU functions necessary to support safety related input, processing, and output shall be considered safety critical
Power supply shall be considered safety critical
PMM shall be considered safety critical
Clocking subsystem shall be considered safety critical
Reset logic shall be considered safety critical
I/O multiplexing (IOMM) shall be considered safety critical
RTI shall be considered safety critical
System control module shall be considered safety critical
ESM shall be considered safety critical
Fuse Farm shall be considered safety critical
OTP configuration shall be considered safety critical
MCU functions necessary to support the safe state shall be considered safety critical
NHET1 shall be considered safety critical
GIO shall be considered safety critical
SIL 3
SIL 3
SIL 3
SIL 3
SIL 3
SIL 3
SIL 3
SIL 3
SIL 3
SIL 3
SIL 3
SIL 3
SIL 3
SIL 3
43
How to implement Diagnostics?
HerculesTM Safety Manual
• 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
44
HerculesTM MCU safety features
Random
Safe Island Hardware diagnostics
CPU Self Test
Controller requires
little S/W overhead
Lockstep CPU &
Lockstep Interrupt
Fault Detection
Lockstep
CPU
ARM®
Cortex® R
w/ MPU
ARM®
Cortex® R
w/ MPU
Physical design
optimized to reduce
probability of common
cause failure
ECC for flash / RAM
evaluated inside the
Cortex R
Memory
Protection
Unit
Memory
Flash
w/ ECC
RAM
w/ ECC
Non Safety Critical Functions
Power, Clock, & Safety
OSC PLL
PBIST/LBIST
POR
ESM
CRC
RTI/DWWD
Flash
EEPROM w/ ECC
Calibration
Compare Module for
Fault Detection
Blended HW diagnostics
Memory Interface
JTAG Debug
Embedded Trace
External Memory
DMA
Enhanced System Bus and lockstep Vectored Interrupt Module
ECC or Parity on
select Peripheral,
DMA and Interrupt
controller RAMS
Parity or CRC in
Serial and Network
Communication
Peripherals
Serial
Interfaces
Network
Interfaces
Dual
ADC
Cores
Available
Dual
High-end
Timers
Available
GIO
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
IO Loop Back, ADC
Self Test, …
Dual ADC Cores with
shared channels
Bold items are introduced with the new Cortex®-R5 devices
45
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?
Hazard & Risk
Analysis
Safety Function
Definition
SIL Determination
(SIL - 1/2/3/4)
Allocation of Safety
Requirements
HW Safety
Requirements
(SFF, PFH)
SW Safety
Requirements
Process Safety
Requirements
46
Estimate MCU SFF / PFH per Safety Function
Use Hercules MCU Detailed Safety Analysis Report & FMEDA worksheet
Set Up Mission Profile
of System
Apply Diagnostics to
Used Modules per
Safety Function
What is the total
failure rate per used
conditions?
Evaluate IEC61508
Failure Rate Summary
N
SFF/PFH
met?
Y
What Self-Test should
be implemented?
Done
47
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
48
IEC61508 HW Metrics Calculation
Failure Rate
Random
Hardware
Failure
Package
Permanent
Die (silicon)
Permanent
Die (silicon)
Transient
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
49
IEC61508 HW Metrics Calculation
Failure Rate / Mission Profiles
Random
Hardware
Failure
Package
Permanent
Die (silicon)
Permanent
Die (silicon)
Transient
50
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
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.04W is based on maximum datasheet value)
Automotive Mission Profile:
Total raw die permanent FIT: 9.48
1.04
Assumed Lifetime
in years
10
Confidence Level
Desired confidence level of FIT rates
70%
Based on RM48x v1.0 FMEDA worksheet
Operational Profile from IEC/TR 62380:2004
Temp1
(tac)1 °C
Profile
32
Temp2
t1
0.02
(tac)2 °C
60
Temp3
t2
0.015
(tac)3 °C
85
Ratios on/off
t3
0.023
Τon
2 night starts
Τoff
0.058
ΔT1 °C
n1
0.942
670
ΔTj/3+55
4 day light
starts
n2
1340
ΔT2
ΔTj/3+45
Non used
vehicle
n3
30
ΔT3
10
51
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
52
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.
53
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 pinlevel application diagnostic
with its own diagnostic
coverage number
54
FMEDA worksheet – Metrics Summary / Details
Summary of IEC 61508 Metrics Examples – Permanent/Transient & Die/Package:
Numbers are normalized to Die Permanent Total RAW FIT
Details of IEC 61508 Metrics:
• For Permanent and
Transient faults
• By modules (CPU,
Flash, SRAM, DCAN,
ADC…)
Based on RM48x v1.0 FMEDA worksheet
55
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, …
FREE!!
 Regular updates for enhancements, fixes, …
Free / click wrap license agreement
SafeTI Compliance Support Package
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 Qualification Kit
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
56
56
HerculesTM Software and Tool Packages
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*
Click Wrap License
Signed License Agreement
Executable Test Cases*
Signed License Agreement
* - these are provided for software that is configurable by user (ie; HALCoGen and CCS Compiler)
57
Software Compliance Support Package Deliverables
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
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
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
Safety Manual
SW Manual
X
software functional safety
assessment plan
software functional safety
assessment report
Functional Safety
Assessment Plan in Safety,
Plan, Functional Safety
Assessment Report
7.4.9- Safety Manual
6.4.9 Safety Assessment
Software
functional
8 safety assessment
Functional Safety
Assessment Plan
Functional Safety
Assessment Report
CP5- Project Closure
CP4- Safety Requirements Verification
& Release
Customer Deliverable
CP3B- Unit Testing & Integration
Testing
IEC61508 Work products
CP3A- Design & Implementation
ISO 26262 Work products
CP2- Safety Requirements & Planning
IEC 61508 Clause
TI SW Product Lifecycle
CP1-Project Commissioning
ISO 26262 Clause
TI Work Products
Generic Inputs- (Can modify during
project tailoring)
ISO 26262 and IEC61508 Standards
X
X
X
X
X
X
X
X
X
58
Hercules RM46 and TMS570LS12x/11x
Hercules
Product
&
Process
Certification
TUEV SUD Certification
13849
•
First devices certified by Exida for IEC 61508 SIL3 use
in 2011
√
61508
•
61508, 26262
•
•
•
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
59
HerculesTM MCUs: Accelerating Safety Products to Market
• Software
• Development Tools
• Consulting & Training
Broad
Eco-system
Hercules
• Ease development
• Aid certification
Unique Tools
for Safety
Development
• Usable by customer
• Certification Ready
• ISO 26262, IEC 61508
compliant
Production
Quality Safety
Software
• Pre-approved for ISO 26262,
IEC 61508
• Safety Analysis Report with
FMEDA, FIT
Certified
Safety
Hardware
Architecture
TM
Safety MCU
ARM based
Lockstep MCU
supplier
Comprehensive
Portfolio
Complementary
Analog
• Non-proprietary
• Market accepted
• Respected heritage
• Pin & SW Compatible
• Safety Chipset
• SafeTI Program
60
Thank You
Contact Information:
Chris O’Brien:[email protected]
Hoiman Low: [email protected]
e ida
61