So, good morning, everybody. And welcome to the WebEx session talking about functional safety standards. And compliance to functional safety standards is becoming a requirement for automotives and many industrial equipments. So today's webinar, hosted by exida and TI, will cover the overview of the functional safety standards, the certification steps, and the [INAUDIBLE] supports to various safety standards. We will have about 50 minutes of presentation, followed by about 10 minutes Q&A. So let's get started. So Chris O'Brien is the principal partner for exida and [INAUDIBLE] functional engineer. So Chris, I will let you get started.
Thank you, [INAUDIBLE]. So I'm going to provide an overview of the functional safety standards starting with IEC 61508, and then talking about some of the [INAUDIBLE] standards, then talk about the steps that are required for an original equipment manufacturer to get their device certified. And touch briefly on the services that exida provides.
So exida is a consulting and certification company. And we help our customers understand, apply, and ultimately get their devices certified to one of the functional safety standards, whether that's IEC 61508 or ISO 26262 or several other ones.
And we help companies in several different areas. We can engage with folks, providing training, tools, such as software tools to do analysis, help to create a knowledge base through books we publish and white papers. We also help organizations as they're in the middle of a project with implementing safety lifecycle services. And then also [INAUDIBLE] some customers desire or need for market reasons third party certification of their products. And we provide that also.
So I want to start by talking about some of the events that led up to what I would call the modern functional safety standards, and primarily the first release of IEC 61508. So if we look at what was going on in the decade or two prior to that standard being released, you'll see that there were several very large and very costly [INAUDIBLE] and economic perspective accidents that really grabbed national and global headlines.
One of those accidents was the Piper Alpha offshore drilling platform. That suffered explosions and caught fire and sank in the North Sea, and 167 people were killed in that. And that was one that kind of caught people's attention because they felt that the best practices had been used, modern equipment had been used, how could we have such a catastrophic event when people felt they had done their best to try to prevent and mitigate that?
Following that accident and other ones, the Health and Safety Executive did a study on basically "Out of Control: Why Control Systems Go Wrong and How to Prevent Failure." So part of the cause of many of these accidents were control systems not functioning correctly. And as the investigations went on, it was found that it wasn't necessarily hardware fault. It could come from many different areas. So the studies found that 44% of the root cause were from improper specifications, either the hazard wasn't properly understood, or it was not properly communicated to the design team.
And then we can go around the pie chart, and we see 15% was design and implementation, 6% was installation and commissioning, 15% was operations and maintenance, and 21% were changes after commissioning. So I'm going to talk in a few slides about what's called the safety lifecycle, but you can see just from this pie chart that the cause of the failures came from many different areas that encompassed the whole design and implementation process.
So that, if we look at the IEC 61508 committee, that was a multi-- it had representation from many different countries on it. It used the recent accidents and investigations, such as the Health and Safety Executive investigation as well as other investigations, to kind of inform it on what was going on with these automated control systems. And they used that as an input for designing and coming up with what was in the 61508 standard.
Now, I'm talking a little bit about 61508 because the concepts in 61508 have since then been applied into derivative standards or industry-specific standards, such as ISO 26262 or IEC 61511. So these concepts of that entire lifecycle and then also systematic and random fault have worked their way into functional safety practice.
Unfortunately-- it would be great to say that, hey, we released the standard 15 years ago, we trained people in industry about it, and we've eliminated these catastrophic events. But unfortunately, that's not the case. And you don't really have to go much past the evening news of the headlines of the newspaper to see it. There was recently the settlement of Toyota and the US Department of Transportation. The upper right hand is an explosion that happened in the UK at a gasoline storage facility in the mid 2000s. And the lower right hand is the BP [INAUDIBLE] platform that had multiple failures that led to another catastrophic failure.
So functional safety-- the goal of functional safety is that an automatic safety function will perform its intended function correctly, or fail in a predictable-- and by predictable, we mean safe-- manner. So the part that related to performing the function correctly is reliability engineering. And that goes into the design and the fault tolerance of the system. And in a predictable manner, or safe manner, is understanding the process and the context, and designing it for the inevitable failure. Because we're never going to be able to design anything that has zero failures, so we have to design it that it's going to fail safely and not cause other problems.
I mentioned the safety lifecycle, and this is a flowchart for the safety lifecycle for IEC 61508. Now, each standards lifecycle is a little bit different, but they all contain similar areas. There typically are three main phases-- first, the analysis phase, then the realization phase, and then the operation phase. So the analysis phase addresses the question of, what should the system do? So, what is the hazard? How do I document that? And how do I conceptually design and write the requirements of how to prevent or mitigate that hazard?
The realization phase, or it could be called the design phase, is taking that safety requirement specification and breaking it into different areas, such as mechanically what needs to be done, electrically what needs to be done, from a software perspective what needs to be done, going through the design process, the integration, and the validation process. And you'll see on the left hand side of the slide, there's the overall planning. So planning is a very important part of the overall safety lifecycle and goes in parallel with the steps.
And then finally, the operation phase is, how do you keep the system performing at the level that it needs to? So, how do you manage change? How do you manage failure mode to demands on the system that weren't anticipated when you first designed it? So, the standard is robust in that it looks at all steps in the entire lifecycle and has requirements, and provides guidance on what should be done.
The other two fundamental concepts from the functional safety standards are strength against systematic faults and strength against random faults. So for example, a software bug is a systematic fault. And that is, that software bug or weakness would be in every single instance of the product, and you mitigate or you minimize them through a robust engineering process with the right checks and balances and rigor in it to design these high availability, high reliability systems.
Then the other area is random failures, and examples of those would be, a resistor would fail some time in its normal life before end of life. Or a spring could break in a mechanical part of the system. And there will be some low frequency of these failures. But you model and do failure mode [INAUDIBLE] diagnostics on the system. And you calculate the probability of failure overall for the system.
So, the functional safety standards introduce a lifecycle, requirements for protection against systematic faults, and requirements for protection against random failures. And those are three key things that I think the standard teaches us. Now, the functional safety standard can be applied-- functional safety standards can be applied at many levels. They could be applied at a component level, such as an MCU, an advanced MCU that's got a lot of capability and a lot of complexity. So that provides the user of that MCU with information and assurance that they can use that in their own complex system. It could be applied at an element level, and that might be a pressure transmitter or an ECU for an offroad vehicle or a safety PLC. Or they can be applied at the system level, and in this case, this is a gas turbine. So it could be a gas turbine certified to the process industry standard.
So, the functional safety standards, I won't say they're confusing. But a difference in mindset is that many standards like electrical safety or pressure equipment standards are prescripted in their nature. And they apply to a very specific application with very specific constraints. The functional safety standards apply to essentially, I need a safety instrumented function or a safety goal to perform in a predictable manner, in a safe manner reliably and fail in a predictable manner. So that's where you can see them applied in many different scales.
So the key driver of all of this is what's called a safety function or a safety goal. And that's a single set of actions and the equipment needed to identify the hazardous event and bring the system to a safe state. So an example could be open a drain valve when a tank level is too high to avoid the hazard of overfilling the tank. And that's what happened in the [INAUDIBLE] accident. It could be to sound an alarm. It could be to provide the right amount of torque in the power assist steering, but not too much and not too little when it's not needed. So the safety goals scale with the project.
Now, an element is defined as a part of a subsystem comprising of single components or a group of components that performs one or more safety function. It can include both hardware and software. And a typical element could be a sensor, a programmable controller, or a final element. So, here we're showing [INAUDIBLE] final element. Within the sensor and within the logic solver, there could be different advanced components, such as an MCU within the final element. You'll typically have separate devices, such as a [INAUDIBLE], an actuator, a valve. And those lower level constituents having safety data and even certification of those lower level elements or parts of the elements very much facilitates getting the system done.
If we break down specifically one of these elements, so if we look at the sensor and look at the transmitter, when you're looking to apply the functional safety standards, you want to be prudent in what you include and what we would call the safety critical path. So, in this case, when looking at a transmitter that's got a sense of pressure, make a decision, conditions and variables, and then write a 420 million amp output. It also has a local interface, and it also has a remote [INAUDIBLE] communications or [INAUDIBLE] communication bus.
Well, you'll notice that the local interface and the heart modem are colored darker gray. And that would indicate that they are not safety critical. So when you're doing a design, you want to be sure you include everything that is safety critical. But if it's not safety critical, you just need to show that it's non-interfering with your safety critical part. So that applies [INAUDIBLE] to a transmitter, but it also applies to an advanced MCU that might have a lot of functionality that you don't need in every application. So having good visibility from your supplier about what's in the MCU, what failure rates are related to what parts of it really can facilitate the design and of a safety related function.
Now, if we look at-- so we've laid a little bit of the groundwork about what the standards are, these elements, they can be controllers or sensors or analyzers within the standard. So let's move a little bit and talk about milestones to get a device certified. So, key milestones are reviewing the product design and the process used to develop it, doing the product reliability and failure mode analysis, looking at how the engineering process meets the standard, and how the design of the product met the requirements for the product, and then finally an audit and assessment of the product and development process.
This is a flow chart of a typical project. In the center are the key steps, and we can kind of break that down into-- and this is a general breakdown. If we look at that start project in green and go down on the left hand side, where we see FMEA, FMEDA, those deal with the random failure rates of the-- and let's just take an electronic control unit as the example. So there's an equipment manufacturer designing an electronic control unit for an offroad vehicle. And they'll have an FMEA of their system, an FMEDA of that control board, and then they'll do a software criticality and hands-off analysis, and if there's communication protocol necessary that isn't certified, that would be reviewed.
That's kind of the functioning of the system. On the right hand side, the gap analysis looks at the development process, looks for weaknesses or gaps in it, and sees how it would correlate to the standards. And there might be additional training needed. There might be procedures needed. But ultimately, that would be in place. The only [INAUDIBLE] safety manual and be audited.
Now, on the left hand side in red are typical documentations and outputs that exida does in a project. And on the right hand side are requirements that an LEM has to prepare as part of their safety gauge. So for example, [INAUDIBLE] tool justification. So if you're using a microcontroller and you're using a compiler, you have to show evidence that that compiler isn't introducing errors or compiling a code in a way that means it isn't going to achieve the safety requirements [INAUDIBLE] safety function. And we'll talk about that in another few slides.
So if you have a new product with no field history, you have to show the new product has a hardware analysis. And that addresses random requirements. The design used to develop that product has to follow a process that meets the 61508 requirements for the target fuel level, and that's to avoid systematic faults. And then you'll have to provide a safety manual for the users so they know how to implement that product successfully so they don't introduce fault. And that's another way to mitigate systematic faults in the operational phase.
So if we look at random failures, the way that they're addressed or analyzed is what's called an FMEDA, a Failure Mode Effective Diagnostic Analysis. So if we roll back to the beginning, these standards are for automatic protection systems. So you're allowed to take credit for diagnostics to either degrade the architecture and say, maybe go from a one out of two to a one out of one, or to bring the process to a safe state because you know your safety interlock no longer is working.
So to do that, you look at failure rates and failure modes for all the components in the-- and again, we're using the ECU as an example in the ECU. So for things like-- for many, many, many devices, exida has a very extensive component database, with failure rates and failure modes. So that's an input. But then if you go to an advanced MCU, where do you get that data? So hopefully, your supplier is going to have a model of their MCU that allows you to say, well, I'm using these functions in the safety critical mode, so I need to include them. But I'm not using these other functions so they're excluded. And it would provide you that information of both failure rates and failure modes as well as the diagnostics you need to implement to achieve certain diagnostic coverage in certain fuel levels. And that usually comes from the safety manual or design kit for the MCU.
That information [INAUDIBLE] FMEDA, the MCU FMEDA, helps with the overall system FMEDA dramatically. And the safety manual and list of diagnostics and maybe even example code help with the software remodel for the ECU manufacturer, because now they can spend their time developing the intellectual property related to their area, say, offroad vehicle control, and pull from a reliable and validated set of diagnostics to help the MCU be more effective and appropriate for a safety application.
Just as an example of how this can be very valuable, and in fact, how if you don't have that support from your MCU supplier, you can really be at a bottleneck in a project, let's look at tool justification. So IEC 61508 and the other standards require the justification of any tool used in the development process. So you go, well, why do they care about that? I write a spec, I code it, I test it, and I'm done.
Well, those using the tool must know how it works, because it could be dangerous. It could change things you don't realize. And anybody using a tool needs to know how it impacts operation. So this is an actual real life example, where we went to do a final audit on a transmitter. And did fault insertion testing, which is a specific type of test that's done to confirm the diagnostics that we're taking credit for work, and it didn't find any fault. So we did a RAM test, and it wasn't picked up. It wasn't caught by the diagnostic.
So what had happened as we dug into it, the software engineer at the OEM had [INAUDIBLE] the optimizer up one level. So the optimizer and the compiler looked through all the code and looked at stuff that wasn't really used much and removed it. So what happened is, that compiled code no longer had diagnostics in it. So that is why it's very important that tools are included.
So for any tool that's used, there is a requirement, justification is required. And specifically, there's three categories, T1, T2, T3. A compiler of T3 [INAUDIBLE]. So for example, you have to have evidence, the tool specification and documentation. You have to identify and mitigate failures that could affect the executable software. So if you don't have good support from that tool supplier, you're going to be trying to do all that by yourself, which may be frankly impractical if not impossible without prior use of that tool. So it kind of limits your selection of microprocessing. You can use the things you've used in the past, and you'd have experience with the compiler list. Or you need to work with a supplier that can give you good support in that area.
Then finally, when all of those steps in that flow chart are completed, or frankly as they're being completed, we create what we call the SafetyCase. And it takes each requirement from the functional safety standards, makes an argument as to why the specific design and development process, meets it, records the evidence, and really creates a very robust trail as to why a transmitter or an ECU or a valve is suitable for a safety rated application.
And we provide certifications. We're ANSI accredited to all of these standards. So we've been-- we're an accredited certification body by ANSI. And we provide cybersecurity as well as functional safety certificates. And just kind of recapping, we provide consulting, product certification, professional certification for people working in the industry, many different training classes, a whole fleet of engineering tools to facilitate the safety lifecycle as well as a large library of reference material. I think with that, I will turn it over to [INAUDIBLE].
Thank you, Chris. My name is [INAUDIBLE], working for Texas Instruments. And I'm working in the safety instrument marketing. And today I would like to give you an introduction of the Hercules MCU family, why it's suitable for use in functional safety applications.
So TI MCU has a very long history in supporting automotive safety applications. We are pretty well known in the automotive braking, such as ADF and stability control system. If you are driving a car today with an EPS or ESP system, the chances are very high that it's powered by a Hercules MCU. And because of its well-known hardware-based architecture, [INAUDIBLE] development process, and also the automotive grade quality, Hercules MCU is also widely used in transportation, industrial, and medical education, where functional safety is a requirement.
So here is the slide showing the product of the Hercules MCU. There are two families. One is the RM family. The other one is TMS570 families. The RM family is targeted for safety critical applications for industrial and medical and features the TI [INAUDIBLE] base MCU running at 330 megahertz, with a [INAUDIBLE] of 550. And the operating temperature is from minus 40 to 105C, which is suitable for rugged industrial applications.
Ethernet, USB, CAN, and UART connectivity modules are also available in RM family. The RM family is designed and developed to IEC 61508 up to SIL-3. The TMS570 family is designed for transportation and automotive applications. It runs from 80 megahertz all the way to 300 megahertz, with a range of flash from 256 kilobytes to 4 megabytes. It's for automotive, so it's a Q100 qualification supported. And the temperature range is minus 40 to 125C.
The automotive communication module, such as FlexRay, CAN, Ethernet, LIN, and UART are available. And because this is for a transportation application, so the TMS570 family is designed to support ISO 26262 up to ASIL-D, and then IEC 61508 up to SIL-3.
And for customers who are new to functional safety standards, it's pretty challenging to understand what it takes to apply the functional safety standards with any equipment. And from a very high level, basically functional safety is about risk reduction. It's reducing risk from an unacceptable level to a tolerable level so that it can be supported, because there's no zero risk in this world for any design.
So the problem [INAUDIBLE] will have to deal with would be, as Chris described, would be the systematic failures and also the random failures that we need to take care. And systematic failure are typically caused by weak development and manufacturing process, inadequate supporting [INAUDIBLE], such as documentation or change management or configuration management, as well as the software and tools, like the compiler as indicated by Chris earlier. And the random failures are failures occurring at random time intervals, causing degradation intrinsically in the hardware. And for example, the flash memory or the SRAM memory could have a [INAUDIBLE] because of defects. And thus what we call the random failure.
For a system to be certified for functional safety standard compliance, evidence of the compliance of the system and also the element and also the components, which is the MCU, will need to be made available to the assessor. And [INAUDIBLE] very response intensive and time consuming. In addition, the validity of the evidence will need to be proven. And so MCU, being a very key component in an electronic programmable system, so the data is very critical. And TI, from [INAUDIBLE], makes available the SafeTI design packages to ease the certification methods for our customers.
So I will explain the steps taken by TI on Hercules MCU to protect against both the random and also systematic failures and the data packages made available to our customers, and how they can be used to facilitate the certification. This slide shows the Hercules MCU safety features to address the random failures. And so the [INAUDIBLE] approach here is to heavily protect critical regions of logic with hardware based diagnostics. And this provides what we call the safe island of logic. And the safe island can detect failure in the remaining device and through the blend of hardware, software, and system diagnostics.
And the safe island hardware diagnostic here on the chart is labeled in red. And the CPU incorporates [INAUDIBLE] architecture and is checking itself on a cycle-to-cycle basis. You can see that the second CPU in this lockstep architecture is being flipped and rotated on a dime, so that we can reduce the probability of a common cause failure.
The flash memory and the RAM memory, they are protected with single error correction and double error detection ECC circuits. And we also have hardware based [INAUDIBLE] engines for the CPU itself, as well as for the HRAM. This is now the factory grade, very high coverage test to be enabled in the applications.
Typically, I will say that a software based CPU self test will probably [INAUDIBLE] a coverage of 90% maximum level, and is difficult to be proven. On the hardware based engine, the [INAUDIBLE] engine, we can reach about 95%, and it's been proven by TI. So our customer doesn't need to prove [INAUDIBLE].
And for the other power for the clock and also the reset, we have for external and internal hardware diagnostic clocks. So as I said, all this hardware-based diagnostic provides enhanced coverage, and most importantly is a known coverage that can be used by a customer in the certification process. The blended hardware diagnostic features are labelled in blue here. And for example, all these peripheral buffers, the RAM, they are protected either by ECC, Error Correction Circuit, or by parity.
And IO for the ADC analog IO, and also digital IO, we have internal loop back to allow self-test. For devices with two ADC, there are shared channels [INAUDIBLE] so that self test is possible using the dual ADC cores in the shared channels. And for ordinary communication modules, parity and CRC are available for error detection.
And so this architecture in the safety architecture concepts has been assessed by [INAUDIBLE]. And their system result is that the safety feature specified approaches diagnostic measure that can reach IEC 61508 [INAUDIBLE] and 26262 [INAUDIBLE]. And so the assessment report can be reviewed by a customer as one of the evidences that the hardware MCU is suitable and can be used in a safety system, where 61508 or ISO 26262 [INAUDIBLE].
One of our development tapes is called Hitex safety kits. The Hitex safety kits enable our developer to evaluate the SafeTI components, if the combination of the Hercules MCU plus a supply and SafeTI monitor chip, called TPS65381. 5 And the kits allow hardware fault injection. And based on the fault injection, the system response can be monitored in real time.
So this is one aspect that Chris touched about earlier in the presentation, is a system will fail. And the functional safety standards, one of the goals is to make sure that when it fails, it fails predictably. So here, the high-tech safety gauge allows you to locate the system response behavior when a fault is injected into the memory, into the power supply, or into the CPU, so that from a system standpoint, we can understand what the behavior, whether it's meeting the requirements or not. The second feature of this high-tech safety kit is to allow you to do a time profiling or for various Hercules MCU diagnostic features.
So I have covered at a very high level the Hercules safety features. And from the TI side, we provide several documentation. One is the safety manual. And the safety manual really summarized the product safety architecture, and also a list for the diagnostic features available by module. So for example, the list of diagnostic features for the RAM, for the flash, for the CPU, for the power supplies, et cetera, can be found in the safety manual.
We also provide the safety analysis report. One is with summary, the other one is with detail. And I'll cover the contents of the safety analysis report in the next slide.
So on the safety manual slide, as I said, it contains all the architecture features and also the diagnostic features by module. And also we provide recommendation whether those diagnostic features should be enabled all the time, whether it's mandatory or whether it's highly recommended, et cetera.
And then the detailed safety analysis report contains the safety metrics and also the use condition. So for example, let's say you're using your MCU for a safety application where you are not using all the resources. Maybe you're only using the CPU, the HRAM, the flash, and maybe some IO channels, [INAUDIBLE] channels, and maybe [INAUDIBLE] module. But you're not using a timer. And so coming with the detailed safety analysis report is the FMEDA worksheet. It contains the failure [INAUDIBLE] module level of an MCU. So this allows our customer to tailor their failure rate calculation based on the actual use condition from the application sample. So this is something that we made available to our customer. And this FMEDA report will be very useful in understanding the actual use condition for the failure rates of the actual use condition.
And so I've covered most of the things that we do to protect us against the random failures. So on the systematic side, what we talk about that's very critical is the development process. So TI is using a development process tailored to IEC 61508 and also ISO 26262 functional standard. And this hardware development process has been assessed and certified by [INAUDIBLE]. And so again, our customer can use this as an evidence showing that the key components in their system was in compliance [INAUDIBLE] process in compliance with the safety standard.
And TI also provides what we call the [INAUDIBLE], which is a GUI-based configurator to generate the drivers. We also provide a SafeTI diagnostic library, which has software API enabling the safety diagnostic as documented in the safety manual. So for example, the safety manual documents that it's mandatory to do, let's say, an HRAM test at startup using the programmable [INAUDIBLE] self-test engine. So in the SafeTI diagnostic library, there will be an API function that allows the customer to enable that self-test function without knowing all the details.
And obviously those drivers and libraries will be integrated into the application software by all customers. And it's our customers' responsibility to certify the application software to the appropriate safety standard. However, TI can ease the certification method by providing what we call the compliance support package that consists of documentation that TI software develops to 61508 and 26262 requirements.
And Chris mentioned about the critically of the compiler in an embedded system development. So true qualification is a critical step to functional safety development. And TI has partnered with [INAUDIBLE] and make available the SafeTI compiler qualification kit.
And the SafeTI compiler qualification kit was developed to help customers in qualifying [INAUDIBLE] the TI compiler to the functional safety standards. And this process can be much less restrictive than certified compilers because I think there are certified compilers available in the market. And typically, they're certified to certain compiler configurations. In here, we are providing a compiler qualification kit so that our customer can choose a use case and then [INAUDIBLE] to qualify the compiler in the use condition selected by a customer.
And so as I said, we have been working this with a third party called Validas. And this kit has been assessed by [INAUDIBLE] to be in compliance with 61508 and also 26262 standard. And so TI, with the compiler qualification kits, is one more way that TI is making it easier for our customer to develop functional safety applications.
So, I'll talk about the Hercules safety architecture, its diagnostic features, and the safety manual, and the very flexible [INAUDIBLE] worksheet, to protect against random failures. And also, our development process, the software, and its compliance support package and the compiler qualification kit to protect against systematic failures for IEC 61508 and 26262 standards. Since all the other industrial or transportation safety standards are referenced to 61508. And so this means that Hercules MCU also is supporting SafeTI [INAUDIBLE] packages also well-suited to be used in the other standards, such as machinery ISO 13849 or IEC 62061 or process safety, the 61511 and railway, 50129, and elevator, 22201. So this table shows a summary of the various safety standards and how Hercules MCU can be used to achieve the desired safety integrity level.
And Chris showed a project flow chart earlier on the certification flow, and what kind of activities need to be done, and what kind of documentation you need to be provided to an assessor as part of the certification process. And so here, from MCU side, MCU is a very critical component in an electronic programmable system. So the documentation is very important to our customer during the certification process.
So Chris talked about the FMEA and FMEDA. So from TI's side, we are providing the safety manual, and also the detailed safety analysis reports with the FMEDA. And the right hand side is all kinds of documentation-- for example, the tool justification, the software process, the coding standard, et cetera, and the safety manual. Those are all made available as part of the SafeTI design package. And so our customer can use that to build a final safety case for their system. And this will help to reduce the amount of time and effort for their certification.
So this concludes our webinar today. So, thank you so much for your time. And stay tuned for the future webinars. We are planning for a second, follow-up webinar to have an in-depth of the functional safety, development and certifications flow. And also some examples of how Hercules MCU documentation can facilitate the end equipment certification process. And so now we open up for questions.
Presentation mode is now disabled.
If there is any question from the audience, the [INAUDIBLE] has been removed.
I want to remind everybody, chat questions to the present also.
Yeah, so could somebody read us the questions, please? Let me see if I can read that.
So, there's a question, what is the difference-- I guess, I don't know if you can see that-- the difference between HLD and SIL-3. They're usually considered to be similar. I don't know about the architecture.
[MICROPHONE FEEDBACK]
I mean, I'm not sure about the [INAUDIBLE] RM MCU in automotive.
Yeah. I would say yes, because the only problem with the RM is the temperature range. And the temperature range is 125C. And so apart from that, from a functionality standpoint, I don't see a problem.
OK. And that would be one thing to be-- so on a certification project for automotive, the profile would be an important consideration, the temperature profile. And if you use a component of-- there's a way to do it. You just wind up modeling a higher random failure rate because the component is used above its design rating. So that would definitely be something to consider, because it may make it not able to achieve it from [INAUDIBLE].
[INAUDIBLE] that used to run continuously for months, or even years, can the self-test be run while the application software is running? Yes. The answer is yes, it's possible. But of course, when you are doing the self-test on CPU and also on the SRAM. That means you need to isolate-- that means the CPU will have to be isolated from the application. And so you need to save and restore the contents [INAUDIBLE] You need to run the self-test and then save and restore the contents, and then restart the application. But it can be done. Same for the memory self-test. It can be done, but of course you cannot access the memory, and you have to restore the contents of the memory after you finish the self-test.
There's another question. It's what is the source of the failure rates data included in the [INAUDIBLE]? OK. So the source of the failure rates data is based on the design database. So in the design database, we did a fault injection by injecting faults into the difference [INAUDIBLE] or the SRAM of the design, and then monitor the approach [INAUDIBLE] diagnostic to see whether that fault can be detected or not. So, this is a very time-consuming process. We did that by actually running [INAUDIBLE] by fault injection. So it's not a pure estimation data, but experimental data based on false injection.
And second thing is, on the FMEDA reports we also have what we call the soft error rate data. And the soft error rate is induced by radiation. And the radiation can cause SRAM bit flip or logic bit flip. And so this is also experimental data that we have done on our MCU in a Los Alamos lab. And so those are based on new experimental data rather than just estimation.
What tools are available to verify in terms of software option code coverage? So there's a question, what tools are available to verify software in terms of object code coverage? And I'm not a software expert, so I need to take that back and get back to you.
Then another question is, does TI provide a basic operating system to euthanize all the self-test and [INAUDIBLE] application developers to run self-test? So TI provided the safety manual. And the safety manual describes the different diagnostic tests that can be implemented by a system developer.
[INAUDIBLE] application is very different from customer to customer, so we do not provide an operating system to utilize all the self-tests, because there are people who doesn't want to [INAUDIBLE] self-test. But we do provide functions so that people can easily call the function using the SafeTI diagnostic library to build up the self-test application software.
How long does the self-test take? So, we can provide you the number. I don't have the numbers offhand. But as you can see, the memory, the programmable memory for the SRAM is obviously very dependent on the memory side. But the self-test I can be sure is very-- can be sure that it's going to be much shorter than the software based self-test. But I need to get back to you on the actual time.
Another question is, what is appropriate [INAUDIBLE] for the confidence input in the [INAUDIBLE]? If the data will be using a [INAUDIBLE] analysis to otherwise [INAUDIBLE] as the source of failure rate for the other component. So I don't know, Chris, whether you have any comments on the [INAUDIBLE].
Well, the [INAUDIBLE] tool, it's a database of component failure rates. I'm not familiar enough with the TI tool to comment on the appropriate confidence input on the [INAUDIBLE].
Yeah. So TI is using [INAUDIBLE] the actual number. It's IEC-- availability manual. And the reason why we're-- there are several reasons why we've chosen to use the IEC, the reliability safety manual, [INAUDIBLE] for FMEDA is because it allows us to go down to the transistor level. And while the [INAUDIBLE] is varied, it's based on components.
So we have one failure rate for the MCU. And we have one failure rates maybe for the [INAUDIBLE] for the RAM. So for us, in order to ensure that we get down to the component level, the transistor level, so that we can also build up the failure rate for MCU as well as the [INAUDIBLE] MCU, and to enable the customization of the failure rate calculation based on use case. And so using the [INAUDIBLE] would be very difficult for us.
I think [INAUDIBLE] the question, do you have a setting on your tool for a confidence factor or a confidence input?
In the Excel worksheet, there's a path that we can input the confidence level that we want to use to estimate the failure rates. And it can be 60%, can be 70% or 99%. Yes, the input service is available.
OK. So I would say from 61508, we need a minimum of a 70% confidence factor for your data. So I would say using the 1H hardware approach-- this is 61508 specific, although I think you could extend it-- so for an architectural requirement, I would recommend the 70. In the 2010 version of 61508, there's is a 2H approach for redundancy. But that requires a 90% confidence interval. So I don't know the confidence interval that's inherent in the [INAUDIBLE] database. But for the functional safety standards, I would recommend the 70 or 90%, depending on which architectural path you wanted to claim. Mostly I would say 70. I think most people would want 70.
So in the [INAUDIBLE] There's a question, will this presentation be made available for offline viewing? Yes. This WebEx has been recorded, and it will be posted online for playback. And the presentation will also be made available.
There's a question, is the model that can do the [INAUDIBLE] using lockstep? Or are they [INAUDIBLE]? So, we have recently done a launch of the new product with the [INAUDIBLE] running at 330 megahertz. And so they are running in lockstep. And so 330 megahertz in lockstep with [INAUDIBLE] to about 500 BMIPs. So yes, they are using lockstep.
OK. So I think our time is up, 11:01. And Chris' contact information and my contact information are there on the slide. And if you have any questions, feel free to send us an email. We'll get back to you. So, thank you for your time.
Thank you.

Details

Date:
March 10, 2015

This is the first of four videos in the functional safety training series. In part one, along with industry partner exida, we provide you with a comprehensive overview of both the IEC 61508 and ISO 26262 functional safety standards, the steps to achieving certification and how certified MCUs support compliance with these various functional safety standards.