This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS570LS0432: FLA1 Diagnostic

Part Number: TMS570LS0432

 Hello,

According to spnu540a.pdf, FLA1 has three possible tests for diagnostic: CPU1,  FLA10, and FLA11.

Do I have to implement all three tests for diagnostic to take credit for FLA1?  I have already done CPU1's test for diagnostic, so I am wondering if it is required to do both FLA10 and FLA11 also.  The spreadsheet around selecting diagnostics doesn't seem to tell me the answer to this question.

Thanks.

  • Hello Colleen,

    The answer is dependent on what safety standard you are targeting. For the automotive standard there are three primary metrics you are striving to meet. These are PMFH, SPFM, and LFM. The use of the tests for diagnostics will generally improve your ability to meet these metrics.

    In regard to using the FMEDA spreadsheet, be sure to look at both the summary pages as well as the detail pages to see if there are any changes to any of the listed metrics. In some cases the changes are very small and negligible with respect to the metrics but should be considered for other reasons. The use of the tests for diagnostics will generally improve your ability to meet these metrics.

    In the case of the CPU1 test for diagnostic, it is monitoring the outputs of the CPUs which includes the ECC logic. So, in short it is a real time monitor of the ECC logic that is used in FLA1. This is an online test meaning that it will detect the fault at the point of use resulting in a single point fault even if it is still protecting the safety function/safety operation of the system.

    In the case of FLA10 and FLA7, these are tests of the safety mechanism outside of the the point of use so they are effective for latent fault detection. i.e., they will detect a fault in the ECC logic potentially before it becomes a fault at the point of use. i.e., it is an effective latent fault detection mechanism. This is important for meeting the LFM targets associated with ISO26262; however, there is no such metric for IEC61508 even if one should still consider latent or residual faults even in IEC61508 systems. Also note that since these tests are testing the fault mechanism in both a postitive and negative way, it is also exercising the error notification path to validate that there are no defects in the logic paths including the ESM as well.

    In short, although there is some commonality in the logic that is tested by these diagnostics, there are also some areas that are unique to the each test. I know this doesn't necessarily answer your question in a direct way, but we are really unable to do so. This is because we do not know your application, your targets for safety, or your specific system level safety goals. In the end, you will need to gauge the overall impact to your system level safety and determine if these are necessary based on their function.
  • Hi Chuck,

    Thanks for the response. I have a followup question about using the spreadsheet in this case.

    If I am using FLA1 as a diagnostic, then I put a 1 next to FLA1 in the "Safety Mechanisms tailoring" tab. It seems to me that in order to take credit for a diagnostic, I need to implement the tests for diagnostic.

    Currently FLA10 and FLA11 are NOT selected in the "Safety Mechanisms tailoring" tab while CPU1 is selected. I am meeting the required diagnostic coverage for my application in the summary tab.

    Does this mean that I do NOT need to implement FLA10 and FLA11?

    Thank for very much for your response. It helps a lot to work through one very concrete example in the spreadsheet.

    Thanks again,
    Colleen
  • Hello Colleen,

    As I noted above, I have no information on your application including which safety standard you are targeting or which safety level, so I cannot answer this. As I noted, there are definitive reasons why we included FLA10 and 11 in the list of tests for diagnostics. If your application does not need to test the error notification paths or if it is tested in some other way, then perhaps these are not needed. In regard to the ECC logic, I believe the coverage should be sufficient.

    A note of caution, we often get caught up in metrics and trying to achieve them but lose sight of the real objective which is to make a safe product. Just because a metric is achieved doesn't mean we should forgo a potential diagnostic if this diagnostic is important to system level safety. In this case, these diagnostics will test the notification path to insure it is functional. You, as the system integrator, have to evaluate the risk of leaving this untested and the potential impact at the system level. You can evaluate the risk by evaluating the FIT rates associated with the FLASH component as well as with the ESM module to determine potential for a fault going unnoticed/detected (dangerous fault or single point fault).

    Also, note that the summary tab is the chip level metrics. You should also have a look at the details for the specific element you are modifying/developing your safety strategy for. This will show small amounts of change that may not show on the summary page. It will also highlight element level coverage and metrics that you must meet for any element used to achieve the safety goal.