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诊断

Guru**** 2460850 points


请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/652820/tms570ls0432-fla1-diagnostic

器件型号:TMS570LS0432

 您好!

根据 spnu540a.pdf、FLA1有三种可能的诊断测试:CPU1、 FLA10和 FLA11。

我是否必须执行全部三个诊断测试才能获得 FLA1的学分?  我已经完成了 CPU1的诊断测试、因此我想知道是否还需要同时执行 FLA10和 FLA11。  有关选择诊断的电子表格似乎没有告诉我这个问题的答案。

谢谢。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好、Colleen、

    答案取决于您所针对的安全标准。 对于汽车标准、您正努力满足三个主要指标。 这些是 PMFH、SPFM 和 LFM。 使用诊断测试通常会提高您满足这些指标的能力。

    关于 FMEDA 电子表格的使用、请务必查看摘要页面和详细信息页面、以查看是否对列出的任何指标进行了任何更改。 在某些情况下、相对于度量标准、变化非常小且可以忽略不计、但出于其他原因、应考虑这些变化。 使用诊断测试通常会提高您满足这些指标的能力。

    对于 CPU1诊断测试、它会监控 CPU 的输出、其中包括 ECC 逻辑。 总之、它是 FLA1中使用的 ECC 逻辑的实时监控器。 这是一个在线测试、意味着它将在使用点检测故障、从而导致单点故障、即使它仍在保护系统的安全功能/安全运行。

    对于 FLA10和 FLA7、这些是在使用点之外对安全机制进行的测试、因此它们对潜在故障检测有效。 即、它们将在 ECC 逻辑中的故障在使用点成为故障之前检测到。 即、它是一种有效的潜在故障检测机制。 这对于满足与 ISO26262相关的 LFM 目标非常重要;但是、即使在 IEC61508系统中仍应考虑潜在或残留故障、IEC61508也没有此类指标。 另请注意、由于这些测试以正极和负极的方式测试故障机制、因此它还会运行错误通知路径来验证包括 ESM 在内的逻辑路径中是否也没有缺陷。

    简而言之、虽然这些诊断测试的逻辑中存在一些共性、但也有一些区域是每个测试所独有的。 我知道这不一定能直接回答您的问题、但我们真的无法这样做。 这是因为我们不知道您的应用、您的安全目标或您的特定系统级安全目标。 最后、您需要衡量对系统级安全的整体影响、并根据其功能确定是否需要这些影响。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    你好、Chuck、

    感谢您的回答。 在本例中、我有一个有关使用电子表格的后续问题。

    如果我使用 FLA1作为诊断、那么我在"Safety Mechanisms Tailing"选项卡中的 FLA1旁边放置一个1。 在我看来、为了获得诊断的学分、我需要执行诊断测试。

    当前、在选择 CPU1时、未在"安全机制定制"选项卡中选择 FLA10和 FLA11。 我在"摘要"选项卡中满足应用程序所需的诊断覆盖率。

    这是否意味着我不需要实施 FLA10和 FLA11?

    非常感谢您的回答。 通过电子表格中的一个非常具体的示例、可以获得很大帮助。

    再次感谢、
    Colleen
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好、Colleen、

    如上所述、我没有关于您的应用的信息、包括您所针对的安全标准或安全级别、因此我无法回答。 正如我所指出的、我们之所以将 FLA10和11包含在诊断测试列表中、有明确的原因。 如果您的应用程序不需要测试错误通知路径、或者以其他方式对其进行了测试、则可能不需要这些路径。 关于 ECC 逻辑、我认为覆盖范围应该足够。

    请注意、我们经常会赶上指标并尝试实现指标、但却忽视了真正的目标、即生产安全的产品。 如果该诊断对系统级安全很重要、仅仅因为达到了指标并不意味着我们应该放弃潜在的诊断。 在这种情况下、这些诊断将测试通知路径以确保其正常工作。 作为系统集成商、您必须评估未测试的风险以及系统级别的潜在影响。 您可以通过评估与闪存组件以及 ESM 模块相关的时基故障率来评估风险、以确定是否存在未注意/检测到的故障(危险故障或单点故障)。

    此外、请注意、摘要选项卡是芯片级指标。 您还应查看您正在修改/制定安全策略的特定元素的详细信息。 这将显示少量更改、但可能不会显示在摘要页面上。 它还将突出显示用于实现安全目标的任何元件的元件级覆盖范围和指标。