Hi. My name is Ashish Vanjari. I work for C2000 safety team. Tuning or customizing a large MCU FMEDA to the application's specific needs is an essential step in system-level safety analysis. In this video, we will see a demo of tuning FMEDA for TI's TMS320F28x7x family of MCU.

This video demo of tuning or customizing TMS320F28x7x FMEDA consists of five parts. In part 1, we will understand what an FMEDA provides as basic contents and how it is useful in system-level safety analysis. In part 2, we will introduce TMS320F28x7x FMEDA spreadsheet, its tabs, and conventions with support tuning to announce the user ability to customize the FMEDA for application's specific needs.

Videos of part 3, part 4, and part 5 will be available on request as part of C2000 SafeTI package. In part 3, we will take a look at detailed view of customization that is supported on TMS320Fx7x FMEDA. In part 4, before we tune the FMEDA, we will take a look at why customization is required for FMEDA and what planning needs to be done before starting it. And finally in part 5, we will see a demo of how to tune TMS320F28x7x FMEDA to satisfy your application's specific needs. And then we will take a look at final results and compare the same before and after tuning.

Let us get started with part 1. For the hardware designs, targeted at safety critical applications, safety analysis is an important step to ensure there is no violation of the safety goal due to malfunctions in hardware components. ISO 26262 function safety standard and command, two methods of safety analysis, mainly, one, deductive analysis and, two, inductive analysis. Deductive analysis is a top down approach of safety analysis, and a common method of top-down analysis is FTA, that is fault tree analysis. Inductive analysis, on the other hand, is a bottom-up approach of analysis, and a common method is FMEA, that is failure mode and effects analysis.

A typical approach at item level is to use the FTA to analyze the violation of safety goal and identify hazardous events down with the component level. Failure modes of the hardware components and its parts are then analyzed from bottom-up analysis using FMEA. This way, FTA and FMEA can be combined for a right balance of top-down and bottom-up safety analysis at item level.

For example, FTA at application level can be initiated to identify basic failure events contributing to the violation of safety goals. This can be supported by FMEA at hardware-component level, which contributes to the list of failure events and respective failure modes. Quantitative data on failure modes become necessary to quantify the risk reduction for the violation of the safety goal.

FMEDA provides information about the failure mode that can be identified and connected to the appropriate FTA events. Thus correlating FMEDA events to FTA events can achieve complete safety analysis at item level. In general, FMEDA analysis at component level helps in conducting abortive analysis.

Does this part fail in this mode? Is the failure of safe or dangerous? Is there a diagnostic or safety mechanism to detect the failure? And what is the effectiveness of the safety mechanism? Finally, how much is this a real risk for violation of the safety goal. A basic MCU FMEDA failure mode effect and diagnostic analysis is a method of analysing impact of diagnostics on identified failure modes.

Quantitative FMEDA can really help in identifying failure modes, the probability of occurrence. There is failure rates and impact of implemented safety mechanisms in terms of diagnostic coverage. This helps interpreting hardware architectural metrics, single point fault metric, that is SPFM, latent fault metric, that is LFM, probabilistic metric of random hardware failures, that is PMHF. This is the end of part 1.