Functional safety Development and

certification Flow
exida / Texas Instruments
Chris OBrien exida, CFSE
Hoiman Low TI Safety MCU, FSCAE
February/2015

e ida

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

IEC 61508 Safety Lifecycle

1

Concept

Overall Scope
Definition

Hazard & Risk

Analysis

Overall Safety
Requirements

Safety Requirements
Allocation

Overall Planning
6

Operation &
Maintenance
Planning

Validation
Planning

Installation &
Commissioning
Planning

Safety-related
systems :
E/E/PES

ANALYSIS
Phases
(What does the product
need to do?)

10

Realisation

12

Overall Installation
& Commissioning

13

Overall Safety
Validation

14

Overall Operation &

Maintenance

16

Decommissioning

Safety-related
systems : other
Technology

11

Realisation

External Risk
Reduction
Facilities
Realisation

REALIZATION
(NPD to meet the
What)

15

Overall Modification
& Retrofit

Copyright exida 2014

OPERATION
(How do we keep the
system functioning
3
safely?)

Product can mean many things

Element
Sensor
Sensor

Logic
Logic
solver
solver

Final
Final
Element
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

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
1n

Elements
1
1n

Component
s

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

IEC 61508 Development Process

Does not show
useful details

Copyright exida 2014

Phase

Product Development Phases

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

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

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

10

System Architecture Design Phase

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

11

System Architecture Steps

Steps can be iterative this is normal.

Create Safety Requirements

Draft Validation Test Plan

Change Safety Requirements

No

Requirements
Testable?

Yes

System Architecture Design

Change Design

No

Design Testable?

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

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

13

Software Design Phase

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

14

Implementation Phase

1. Create and Inspect Code

2. Perform Static Analysis on Code
3. Unit Test Code must be documented and traceable
Copyright exida 2014

15

Integration and Validation Test

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

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

15. overall modificaton

and retrofit

Functional Safety Assessment

2. Overall scope
definition

Verification

Management of Functional Safety

Documentation

1. Concept

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

Software
Design
Review /
Analysis Report
Software
Module Test
Plan/Report
User
Installation
Manual /
Safety Manual

Modification

Copyright exida 2014

Safety
Requirements
Specification

23

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?

Copyright exida 2014

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

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
Change Management
V&V

How to manage MCU hardware

random failures
How to estimate failure rate vs SIL
requirements
Software support

Random Failures
Diagnostics
Architectural Metric

Personnel Competence

Failure Rate
Certification

Workshop will address:

TM
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

How to calculate all these?

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
)
MCU

SRAM failure rate

(SRAM
)
SRAM

CPU failure rate

(CPU
)
CPU

Flash failure rate

(Flash
)
Flash

Apply SRAM
Diagnostics

Apply CPU
Diagnostics

Apply Flash
Diagnostics

Failure rate analysis

SRAM
SRAM
SAFE,
DD, DU
SAFE, DD,
DU

Failure rate analysis

CPU
CPU
SAFE,
DD, DU
SAFE, DD,
DU

Failure rate analysis

Flash
Flash
SAFE,
DD, DU
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
Voltage
Regulator
Regulator

Motor
Torque
Command
from
Remote
Host

5-16MHz
5-16MHz
Clock
Clock Crystal
Crystal

1.2v 5v 3.3v
Pre
Pre Drivers
Drivers

nPORRST

DCAN1

Safety Function Input

(MCU)

Hercules 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
Quadrature
Encode
Encoderr

OSCIN OSCOUT

System Reset

fety Goal: The motor shall deliver torque as commanded by the external host.

eQEP

GIO

Warning
Warning
Lamp
Lamp

Safe State (MCU)

1. Disable motor driver
relay (NHET)
2. Indicate fault to
system via warning lamp
(GIO)
Safety Function
Actuation (MCU)

ePWM1
ePWM2

Pre
Pre Drivers
Drivers

ePWM3

NHET1

H
H Bridge
Bridge
Drivers
Drivers

Motor Position Feedback

41

Drive three phase PWMs

to actuate motor (ePWM)

BLDC
BLDC
Motor
Motor

MCU Safety Critical Elements

per Safety Function

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

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
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

SatisfiesAssumed Safety Diagnostic Requirement

SF_1
MCU safety related functional input shall be considered safety critical
SFR_1
DCAN1 shall be considered safety critical
SFR_1
eQEP1 shall be considered safety critical
SF_1
MCU safety related functional output shall be considered safety critical
SFR_2
ePWM1 shall be considered safety critical
SFR_2
ePWM2 shall be considered safety critical
SFR_2
ePWM3 shall be considered safety critical
SF_1
MCU safety related processing shall be considered safety critical
SFR_3
Cortex R4F CPU shall be considered safety critical
SFR_3
TCM SRAM as needed to support the application shall be considered safety critical
SFR_3
TCM Flash as needed to support the application shall be considered safety critical
SFR_3
L2/L3 interconnect as needed to support the application shall be considered safety critical
SFR_3
VIM shall be considered safety critical
MCU functions necessary to support safety related input, processing, and output shall be
SF_1
considered safety critical
SFR_4
Power supply shall be considered safety critical
SFR_4
PMM shall be considered safety critical
SFR_4
Clocking subsystem shall be considered safety critical
SFR_4
Reset logic shall be considered safety critical
SFR_4
I/O multiplexing (IOMM) shall be considered safety critical
SFR_4
RTI shall be considered safety critical
SFR_4
System control module shall be considered safety critical
SFR_4
ESM shall be considered safety critical
SFR_4
Fuse Farm shall be considered safety critical
SFR_4
OTP configuration shall be considered safety critical
SF_1
MCU functions necessary to support the safe state shall be considered safety critical
SFR_5
NHET1 shall be considered safety critical
SFR_5
GIO shall be considered safety critical

43

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
SIL
SIL
SIL
SIL
SIL
SIL
SIL
SIL
SIL
SIL
SIL
SIL
SIL
SIL

3
3
3
3
3
3
3
3
3
3
3
3
3
3

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

CPU Self Test
Controller requires
little S/W overhead

Lockstep CPU &

Lockstep Interrupt
Fault Detection

Memory
Protection
Unit
Lockstep
CPU
ARM
Cortex R
w/ MPU

Safe Island Hardware diagnostics

ECC for flash / RAM

evaluated inside the
Cortex R

ARM
ARM
Cortex
Cortex R
R
w/
w/ MPU
MPU

Physical design
optimized to reduce
probability of common
cause failure

Random

Compare Module for

Fault Detection

Blended HW diagnostics
Non Safety Critical Functions

Memory
Flash
w/ ECC
RAM
w/ ECC
Flash
EEPROM w/ ECC

Power, Clock, & Safety

Calibration
JTAG Debug

Memory Interface

OSC PLL

PBIST/LBIST

POR

ESM

CRC

RTI/DWWD

Embedded Trace

Memory BIST on all

RAMS for fast
memory test
Error Signaling
Module w/ External
Error Pin

External Memory

On-Chip Clock and

Voltage Monitoring

DMA

ECC or Parity on
select Peripheral,
DMA and Interrupt
controller RAMS
Parity or CRC in
Serial and Network
Communication
Peripherals

Enhanced System Bus and lockstep Vectored Interrupt Module

Serial
Interfaces

Network
Interfaces

Dual
ADC
Cores
Available

Protected Bus and

lockstep Interrupt
Manager

Dual
High-end
Timers
Available

IO Loop Back, ADC

Self Test,

GIO

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

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

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

Die (silicon)
Transient

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

Automotive Mission Profile:

Total raw die permanent FIT: 9.48

Customer input for transient fault estimation

1
Application specific Flux Factor coeff. based on Jedec JESD89A

Based on RM48x v1.0 FMEDA worksheet

Maximum power dissipation

Application specific power dissipation in Watts

1.04
51

(1.04W is based on maximum datasheet value)

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*

Executable Test Cases*

Click Wrap License

Signed License Agreement
Signed License Agreement
* - these are provided for software that is configurable by user (ie; HALCoGen and CCS Compiler)

57

Software Compliance Support Package Deliverables

ISO 26262 and IEC61508 Standards

ISO 26262 Clause

IEC 61508 Clause

TI Work Products

ISO 26262 Work products

IEC61508 Work products

TI SW Product Lifecycle
Gen
eric
Input
s(Can
modi
fy
durin
g
proje
ct
tailori
ng)

Customer Deliverable

CP
1Pro
ject
Co
m
mis
sio
nin
g

CP
2Sa
fet
y
Re
qui
re
me
nts
&
Pl
an
nin
g

C
P3
ADe
sig
n
&
Im
ple
m
en
tati
on

CP3
BUnit
Testi
ng &
Integ
ratio
n
Testi
ng

CP4Safet
y
Requ
irem
ents
Verifi
catio
n&
Rele
ase

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

Bi-Directional Traceability

Forward and Backward

Traceability at all stages

Verification Reports

Forward and backward

traceability

Traceability matrix

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

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

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

Safety Manual

SW Manual

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

CP5Project
Closur
e

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

TV-SD certified the SafeTI Hardware functional

safety development process in 2013 for:

61508

IEC 61508 SIL-3

ISO 26262 ASIl-D

61508, 26262

Hercules MCUs assessed for IEC 61508 SIL-3 and ISO

26262 ASIL D:
Hercules Safety Architecture
Device

TV-SD 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

Pre-approved for ISO 26262,
Pre-approved
IEC 61508 for ISO 26262,
IEC
61508Analysis Report with
Safety
Safety
Analysis
FMEDA,
FIT Report with
FMEDA, FIT

Software
Software
Development Tools
Development
Consulting Tools
& Training
Consulting & Training

Hercules
Ease development
Ease
Aiddevelopment
certification
Aid certification

Usable by customer
Usable
by customer
Certification
Ready
Certification
Ready
ISO 26262, IEC 61508
ISOcompliant
26262, IEC 61508
compliant

TM

Non-proprietary
Non-proprietary
Market accepted
Market
accepted
Respected
heritage
Respected heritage

Safety MCU

Pin & SW Compatible

Pin
& SW Chipset
Compatible
Safety
Safety
Chipset
SafeTI
Program
SafeTI Program

60

Thank You
Contact Information:
Chris OBrien:cobrien@exida.com
Hoiman Low: hm-low@ti.com

e ida

61