TI Safety MCUs in Industrial

Functional safety Development and certification Flowexida / Texas Instruments

Chris OBrien exida, CFSE Hoiman Low TI Safety MCU, FSCAEFebruary/2015

#Back in June, exida and TI have covered the overview of functional safety standards, the certification steps and the Hercules MCU family support to various functional safety standards.

Today we will discuss in more details regarding the certification requirements and how Hercules MCU documentation can significantly ease the certification effort. We will have about 50 minutes presentation followed by 10 minutes Q&A. Please send your questions through the chat panel.1TopicsexidaIEC 61508 Safety LifecycleImplementing a Compliant New Product Development ProcessFunctional Safety ManagementDocumentation RequirementsCertification to Functional Safety StandardsTexas InstrumentsHerculesTM MCU Functional Safety How-To WorkshopSafety Functions, Safety Goals, Safe State, SIL, Failure rateSafety Critical Elements identification and Diagnostic RequirementsSafety Manual and Diagnostics SelectionMission Profile and Failure Rate EstimationSafeTITM Diagnostic LibrarySafeTITM Diagnostic Library Compliance Support Package (CSP) certification supportSummary

2

2IEC 61508 Safety Lifecycle3ANALYSIS Phases(What does the product need to do?)REALIZATION (NPD to meet the What)ConceptOverall ScopeDefinitionHazard & RiskAnalysisOverall SafetyRequirementsSafety RequirementsAllocationSafety-relatedsystems :E/E/PESRealisationOverall Installation& CommissioningOverall SafetyValidationOverall Operation &MaintenanceDecommissioningSafety-relatedsystems : otherTechnologyRealisationExternal RiskReductionFacilitiesRealisationOverall PlanningInstallation &CommissioningPlanningValidationPlanningOperation &MaintenancePlanning111095432112131416Overall Modification& Retrofit15876OPERATION(How do we keep the system functioning safely?)Copyright exida 20143The IEC 61508 safety lifecycle is one of the more comprehensive guidlines for how to effecively achieve functional safety through the use of safety instrumented systems.SensorLogic solverFinal Element

4Elementelement - part of a subsystem comprising a single component or any group of components that performs one or more element safety functions.[IEC62061, 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 thingsCopyright exida 201445SystemsSub-SystemsElementsComponents11-n11-n11-nThe 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 LevelsCopyright exida 20145Safety Lifecycle RequirementsRequirementsMust show sufficient design quality / integrityOPTION 1: Fully Compliant ProcessOPTION 2: Proven In UseOPTION 3: Combination

Systematic CapabilityIEC 61508-2010Measure (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.

6Copyright exida 20146IEC 61508 Development Process7

Does not show useful detailsCopyright exida 20147Product Development - Phases8PhaseProcess Steps in PhaseSafety RequirementsCreate and Inspect Product Safety RequirementsSafety Validation Test PlanningCreate and Inspect Safety Validation Test PlanSystem Architecture DesignCreate and Inspect System Architecture DesignPerform System FMEACreate and Inspect Derived Safety RequirementsCreate and Inspect Integration Test PlanHardware DesignPerform Detailed Hardware DesignPerform Hardware FMEDAPerform Fault Injection TestingSoftware DesignCreate and Inspect Software ArchitecturePerform Software Criticality Analysis and HAZOPCreate and Inspect Detailed Software DesignImplementationCreate and Inspect CodePerform Static AnalysisUnit Test CodeIntegration and Safety Validation Test ExecutionPerform Integration TestingPerform Validation TestingCopyright exida 20148Safety Requirements Phase9

Market RequirementsCustomer RequirementsUse CasesSIL Capability, SIL Certification LevelsRegulatory Requirements

For general purpose products, SIL requirements cannot come from a specific application hazard analysisCopyright exida 20149Safety Validation Test Plan Phase10

Create and Inspect a Validation Test Plan that contains at least high level test objectives.Every requirement must have a test.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 20141011System Architecture Design Phase

Create and Inspect an overall design by partitioning functions into sub-functions classical engineering process. Perform System FMEA to verify design integrity. Update requirements and validation test plan.Copyright exida 201411System Architecture Steps 12Create Safety RequirementsSystem FMEASystem Architecture DesignNew Safety RequirementsDraft Validation Test PlanChange Safety RequirementsRequirements Testable?Design Sufficient?NoYesAllocate Safety RequirementsYesNoHardware DesignSoftware DesignSteps can be organized and named in any way.Steps can be iterative this is normal.Draft Integration Test PlanDesign Testable?NoYesChange DesignCopyright exida 201412Hardware Design Phase13

Perform detailed hardware design including component selection. Many components are IEC 61508 certified.Perform hardware FMEDA.Build Hardware prototypes fault injection test.Copyright exida 201413Software Design Phase14

Create and Inspect Software Architecture typically block diagram, entity relationship drawings, state diagrams, etc. Perform Software Criticality Analysis and HAZOPCreate and Inspect Detail Software Design.Copyright exida 201414Implementation Phase15

Create and Inspect Code Perform Static Analysis on CodeUnit Test Code must be documented and traceableCopyright exida 201415Integration and Validation Test Copyright exida 201416

Perform Integration Testing must be documented with test plans and test resultsPerform Validation Testing must be documented with test plans and test results, show traceability to all safety requirements.16Product Development Process RequirementsThis 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

Copyright exida 201417Functional Safety ManagementObjectives and RequirementsSpecify engineering process including each step with input and output documents. Control and manage documentationSpecify responsibilities of persons and organizationsEvaluate competency of those assigned to rolesEvaluate Quality Management of SuppliersEstablish a system to monitor product quality and safety for the lifetime of the product18Copyright exida 201418Management of Functional Safety191. Concept2. Overall scopedefinition3. Hazard andrisk analysis4. Overall safetyrequirements 5. Safety requirementsallocation6. Overall operation and maintenance planning 7. Overallsafetyvalidationplanning 8. Overallinstallation andcommissioningplanning 9. SRSE/E/PESrealization12. Overall installationand commissioning 13. Overall safetyvalidation14. Overall operation,maintenance, repair16. Decommissioningor disposal 15. overall modificatonand retrofit Management of Functional SafetyDocumentationVerificationFunctional Safety AssessmentBack to appropriateoverall safety lifecyclephaseCopyright exida 201419Defined Engineering ProcessObjective: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.

20Copyright exida 20142021

Often a flow chart is used to provide an overview.Defined Engineering ProcessCopyright exida 201421Documentation ObjectivesWhat needs to be documented?

Any information to effectively perform: Each phase of the safety life cyclesThe management of functional safetyVerificationFunctional Safety Assessment

22Copyright exida 201422Typical Documentation23Hardware DesignSoftware DesignE/E/PE IntegrationModificationE/E/PE ValidationE/E/PE Safety Requirements SpecificationSafety Requirements SpecificationFunctional Safety Management PlanVerification and Validation Plan/ReportUser Installation Manual / Safety ManualDesign SpecificationChange Request DatabaseFMEDA ReportIntegration Test Plan / ReportSoftware Module Test Plan/ReportSoftware Review / Analysis ReportCopyright exida 201423DocumentationDocumentation Requirements:Title indicating the Scope of the ContentsLegal entity (e.g. company, author(s), etc); Scope and purposeRevision Index (Version Numbers) Table of Content and IndexTraceability to functional and SI requirements Inputs and outputsHow 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?24Copyright exida 201424Process VerificationObjective:evaluate the outputs from a given process step to ensure correctness and consistencyRequirements:plan verification concurrently with developmentverify in accordance with plandocument 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 resolutionProblem issues must be addressed by returning to the appropriate process step.25Copyright exida 201425

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

Process VerificationCopyright exida 201426New 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.27Random Failure IntegrityProduct Systematic Failure IntegritySystem Systematic Failure IntegrityCertification ProcessCopyright exida 201327

Copyright exida 201428AccreditationEach Certification Body (CB) operates per a scheme and gets accredited by an Accreditation Body (AB). In the USA, ANSI is the AB.

29Functional Cyber-SecurityAchilles Level 1-2ISA Secure Levels 1 3Functional Safety CertificationIEC 61508IEC 61511IEC 62061 / ISO 13849IEC / ISO 26262EN 50271Other Functional Safety

Copyright exida 2014Exida is accredited by ANSI, the US accreditation body.29TopicsexidaIEC 61508 Safety LifecycleImplementing a Compliant New Product Development ProcessFunctional Safety ManagementDocumentation RequirementsCertification to Functional Safety StandardsTexas InstrumentsHerculesTM MCU Functional Safety How-To WorkshopSafety Functions, Safety Goals, Safe State, SIL, Failure rateSafety Critical Elements identification and Diagnostic RequirementsSafety Manual and Diagnostics SelectionMission Profile and Failure Rate EstimationSafeTITM Diagnostic LibrarySafeTITM Diagnostic Library Compliance Support Package (CSP) certification supportSummary

30

30Applying Functional Safety Standards31HerculesTMArchitecture(FMEDA)SafeTI design packages help meet functional safety requirements while managing both systematic and random failures.

Systematic FailuresToolsSafety PlanDocumentationConfig ManagementChange ManagementV&VPersonnel CompetenceCertificationSIL - 1/2/3/4Functional SafetySafety Life CycleRisk reductionSoftwareRandom FailuresDiagnosticsArchitectural MetricFailure RateCSP = Compliance Support Package

Development ProcessWorkshop will address:How to manage MCU hardware random failuresHow to estimate failure rate vs SIL requirementsSoftware supportFor companies who are new to functional safety standards, it is challenging to understand what it takes to apply the functional safety standard to its end equipment.From a very high level, functional safety is about having a robust development process as well as risk identification and reduction - reducing risk from an unacceptable level to a tolerable level. Risks associated with systematic failures and random failures need to be identified. Their effects need to be analyzed so that appropriate measures can be implemented to reduce the risk impact.Systematic failures are caused by weak development and manufacturing process, inadequate supporting process such as documentation, configuration management. Development tools and software are also sources of systematic failures.Random failures are failures occurring at random time causing degradation in the hardware, such as a logic gate output stuck at fault or an external disturbance induced SRAM bit flip.3132DevelopmentProcessSoftwareFunctional Safety CertificationHardwareMCUHardwareSafety MetricMCUSoftwareDrivers, LibraryToolMCUDevelopment Process

SystemShow me evidenceFunctional safety certification is done at the system level. During certification, the system and its components compliance evidence will need to be made available to the assessor. This is resource intensive and time consuming. The validity of the evidence will also need to be proven.

3233SIL Determination(SIL - 1/2/3/4)Safety Function DefinitionSW Safety RequirementsAllocation of Safety RequirementsHazard & RiskAnalysisHW Safety Requirements(SFF, PFH)Process Safety RequirementsIEC 61508Hazard/Risk Analysis & SIL determinationAt the system level, hazard and risk analysis are done. Safety function is derived from the hazard analysis. Safety Integrity Level is derived from the risk assessment. Once the safety requirements are identified, it is allocated to different elements within the system. These drives the hardware, software/tools and process safety requirements for the MCU.3334Safety Function / Safe State

SensorActuatorMCUHazard 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 achievedHere is an example of Safety Instrumented System with a sensor, logic solver and final control element implemented with sensor, MCU and actuator.

3435Safety Function / Safe StateHazard: 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

SensorActuatorMCULets assume that the hazard in this example is high gas flow pressure. The safety function is to monitor the gas flow pressure. If the pressure is too high, the gas flow will be shut off. If any dangerous fault is detected in the system, it should transition to the safe state which is turning off the gas flow.3536Risk Analysis / Safety Integrity LevelRisk 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

SensorActuatorMCUSafety Integrity Level is derived from the risk. The risk is determined by the frequency of the hazardous event and its consequence. Assuming that the consequence of an hazardous event will be an explosion causing injury and death as well as property damage, the Safety Integrity Level will probably be defined as SIL3 in this example.3637Safety Integrity LevelSafety 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?Safety Integrity Level is characterized by a set of metrics. For IEC 61508, they are Single Failure Fraction (SFF), Probability of dangerous Fail on Demand Average (PFDavg) for low demand operations and Probability of Dangerous Fail per Hour (PFH) for hifh demand operations.

SFF is a measure of safeness of a system. It is a relative metric. PFH is a measure of failure rate due to dangerous undetected failures. It is an absolute metric.

3738Safety Integrity LevelSILSFF (HFT=0)PFH (FIT)SIL10%