[参考译文] TMS570LS3137：故障注入测试的方法

因此(1)是计算 ECC 错误并进行跟踪的逻辑

您可能实际上在询问7.119 "Software Test of ECC Profiler"。 ？

对于(2)、不是"可能的诊断测试"列中列出的测试。您可能会运行这些测试来激励此路径。

你好 Anthony。
感谢你的答复。

>也许您实际上在问7.119“ECC Profiler 的软件测试”。 ？
它略有不同。
我认为这个测试被确认为机制"主 SRAM 可纠正 ECC 参数描述"、但是不会将故障注入到"主 SRAM 可纠正 ECC 参数描述"。 你怎么看？

因为(2)是我理解的。谢谢。
不能实现故障注入测试的安全机制也不是必需的。

此致

Arriy、

如 Anthony 所述、诊断"主 SRAM 可纠正的 ECC 剖析"用于监控 ECC 事件。 在某些情况下、这用于检测大量可纠正的错误、这些错误表示 MCU 在风险增加的环境中运行(其他因素对 RAM 位完整性的影响较高)。 监控此指标的应用程序可能会使用此计数将器件置于安全状态、直到发生损坏、或者直到根据应用要求进行下一个下电上电。

从诊断测试的角度来看、不可能在器件级的 ECC 分析逻辑中插入故障。 它只能在用于生成芯片的代码上的仿真期间完成、这正是我们为时基故障率计算模型所做的。 对于逻辑中的潜在故障检测、我们使用函数诊断的软件测试来测试 ECC 分析是否按计划工作。 这是通过创建具有单个位错误的存储器位置、读取该位置并验证性能评测计数是否递增来实现的。 这可以在启动(引导时间)或定期基础上完成、具体取决于应用吞吐量需求。

对于错误路径的 ESM 软件测试、它再次是一个功能证明测试、以确保故障检测机制和故障通信机制(ESM)之间的逻辑路径运行正常。 在测试故障的路径中不可能产生故障、因为故障只是 ESM 中的错误通知不会发生。 更谨慎的测试是为了确认路径按预期工作、并且除预期的错误外、不会看到任何其他错误。 这些测试可与许多针对大多数元件推荐的"包括错误测试在内的功能测试的软件测试"中的一个组合使用。

此外、正如 Anthony 所说的、没有必要并且通常不可能为每个主要诊断插入故障、但在您努力考虑 ISO26262时、有一些计数器测量和重叠用于识别潜在故障。 安全手册表 A 的诊断测试列中列出了计数器测量值和过载诊断。

此外、更确切地说、根据 IEC61508标准、故障注入和故障插入之间存在很大差异。 对于器件、只能进行故障插入、因为您无法访问器件、并且无法在物理上创建故障。 从系统层面而言、这可能是可行的、因为您在系统层面进行控制、从而在电路中产生可能被视为故障注入的误差。 还值得注意的是、术语通常可互换使用、但这不正确。