functional safety development and certification flow · pdf filefunctional safety development...

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


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


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


Management Plan



Design

Perform System FMEA


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.


11

System Architecture Design Phase

evelopment Process Overview

Project Management System ngineering Hardware evelopment Software evelopment System Validation

Project Approved



Create and InspectDerived SafetyRequirements


Management Plan



Design

Perform System FMEA

Perform DetailedHardware Design

including componentselection

Create and InspectSoftware Architecture

Design

Create and InspectIntegration 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.


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


Hardware Design Phase

13


esign

Perform System FM A



Perform HardwareFMEDA


Design

Create and inspectdetailed software design


Perform SoftwareCriticality Analysis and

HAZOP

Create Code

Create and InspectSafety Manaual

Build HardwarePrototypes


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.


Software Design Phase

14


esign

Perform System FM A



Perform HardwareFMEDA


Design




HAZOP

Create Code

Perform Static Analysiswith PC LINT



Create DetailedValidation Test

Procedures


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.


Implementation Phase

15

Perform HardwareFM A



HA OP

Create Code

Perform Static Analysiswith PC LINT

Inspect Code



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


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


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


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


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.


21

Often a flow chart is used to provide an overview.

Defined Engineering Process


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


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


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?


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.


26

Recommend checklist at end of each phase completed during or after phase review meeting.

Process Verification


• 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


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


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

http://www.ti.com/safeti

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


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


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

http://www.ldra.com/images/related/90c2f70276f86f430bb0d1116b5fc543.jpg

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

functional safety development and certification flow · pdf filefunctional safety development...

Documents