[参考译文] RM48L952：SafeTI：FLASH_ADDRESS_奇 偶校验_self_test 信号演示项目中应用程序的实际组3错误 ANBD 出于相同的原因不能在&quot 中使用；实应用程序要么不能使用&quot；

这是在启用 FIQ 时看起来也能在运行时工作的代码


DATA_ABORT()检查是在 FIQ 中断后通过适当的诊断模式检查的这种可能的闪存地址奇偶校验测试"剩余"调用
否则、if ((((TRUE == sl_FLAG_GET ((Int32) FLASH_ADDRESS_奇 偶校验_自_测试)))&(((sl_flashWREG->FDIAGCTRL & 0x7U)== 7U)))
｛//注意：JSI 14.6.2017：如果启用了 FIQ、此测试也会导致数据中止
maskDAbort = true；
｝
/*由于闪存包装程序测试2位 ECC 故障注入而导致的 DAbort？ *
否则(0U！=(sl_flashWREG->FDIAGCTRL & 0x7U))



sl_selftest.c "被严重修改"以检查 FIQ 是否被启用、并根据它采取适当的操作(清除此处的组3、因为错误是由 SafeTI 引起的)

_sl_Barrier 数据访问()；
flashread =*(volatile UINT32 *) flashBadECC1；

sl_flashWREG->FPAROVR = regBkupFPUvr；//在错误后、在新的闪存访问之前立即返回内容
sl_flashWREG->FDIAGCTRL = regBckupFdiagctrl；//此处已恢复相同

if (flash_address_parity、fault_inject！= testType)
｛
extern uint32 _fiq_disable_(void)；
布尔型 bGroup3Ok = true；

//注意：只有启用 FIQ 才会生成数据中止，因此组3错误可能存在，也可能不存在
if (!_Fiq_disabled_())
｛
if (((F021F_FEDACSTATUS_B1_UNC_ERR =(uint32)(sl_flashWREG->FEDACSTATUS & F021FEDACSTATUS_B1_UNC_ERR)))
&&(sl_flashWREG->FUNCHERRADD =>(uint32) 0x0u)&&(位(ESM_G3ERR_FMC_Uncorr)==(sl_esmREG->SR1[2]和位(ESM_G3ERR_FMC_Uncorr)))))
｛
｝
其他
｛
bGroup3Ok = false；
｝

/*始终清除闪存和 ESM 状态寄存器*/
SL_flashWREG->FEDACSTATUS = F021F_FEDACSTATUS_B1_UNC_ERR；
sl_esmREG->SR1[2]=位(ESM_G3ERR_FMC_Uncorr)；
//请勿读取 sl_flashWREG->FUNCHERRADD，它如下所示
｝

if (bGroup3Ok)
｛
if (((F021F_FEDACSTATUS_ADD_PAR_ERR =(uint32)(sl_flashWREG->FEDACSTATUS & F021FEDACSTATUS_ADD_PAR_ERR))))
｛
//sl_flashWREG->FPAROVR = regBkupFPUVr；
_sl_HoldNClear_nError()；/*清除 nError */
/*清除闪存和 ESM 状态寄存器*/
//sl_flashWREG->FEDASTATUS = F021F_FEDASTATUS_ADD_PAR_ERR；//两次，也在下面
//sl_esmREG->SR1[1]= GET_ESM_bit_NUM (ESM_G2ERR_FMC_Uncorr)；//两次，也在下面
//flashread = sl_flashWREG->FUNCHERRADD；
*FLASH_stResult = ST_PASS；
}否则{
*FLASH_stResult = ST_FAIL；
｝
｝
其他
｛
*FLASH_stResult = ST_FAIL；
｝

/*SAFETYMCUSW 134 S MR：12.2 备注_5*/
/*SAFETYMCUSW 96 S MR：6.2、10.1、10.2、12.1、12.6 备注_25*/

/*始终清除闪存和 ESM 状态寄存器*/
SL_flashWREG->FEDACSTATUS = F021F_FEDACSTATUS_ADD_PAR_ERR；
sl_esmREG->SR1[1]= GET_ESM_bit_NUM (ESM_G2ERR_FMC_Uncorr)；
sl_esmREG->SSR2 = GET_ESM_BIT_NUM (ESM_G2ERR_FMC_Uncorr)；
flashread = sl_flashWREG->FUNCHERRADD；

/*清除诊断模式设置*/
sl_flashWREG->FPAROVR = regBkupFPUVr；
sl_flashWREG->FDIAGCTRL = regBckupFdiagctrl；
｝


另请注意、如果启用了 FIQ、这些类型的寄存器清除完全没用(可能会防止"同时到达可能的实际错误"？) 由于 FIQ 中断处理会自动清除 SR[1]位、因此只有 SSR2位保持活动状态、需要确认...
sl_esmREG->SR1[1]= GET_ESM_bit_NUM (ESM_G2ERR_FMC_Uncorr)；


是的、诊断寄存器备份恢复在这里是两次、因为不想修改超出必要的代码...

这不能是 SafeTI 库的用途、集成商需要根据寄存器设置来访问"私有函数" sl_FLAG_Get、Guess 和 Wonder、这些设置可能正在进行、尤其是在演示应用甚至不是故意处理情况时 (嗯、如果/何时演示应用程序停止到 DMA 测试、甚至无法继续执行这些测试、这正是您所期望的...)。


再次询问、当 SafeTI 的固定版本即将推出时，当前的2.3.1以多种方式被破坏-是的，您可以忍受这种情况(希望您不能修改它：) 但需要对 TI 代码进行"大量修改"、并花费不必要的时间来首先找出根本原因、然后自行修复？

您好、Jarkko、

我想发送一条简短的消息、让您知道我们已经与本测试设计的原始软件进行了交谈、但我们尚未收到可接受的最终答案。 设计人员的初始响应是将 ESM 处理程序从 SRAM 中执行、以防止异常、我认为这是集成到真实安全应用中的可接受解决方案。 我们将继续研究如何确定修复它的最佳解决方案、并避免将任何元素移至 SRAM 执行。

您好！

只是为了澄清：这是否意味着、在当前形式的代码中、如果启用了 FIQ、那么组3错误+中止是运行此测试的"实际且预期"副作用-而不是我一侧的某种编码错误？

如果这是真正的确定性副作用、我至少可以忍受该组3错误、因此我不需要从 RAM 运行代码来防止它发生或其他任何更复杂的事情-如果这种行为、我可以很容易地看到 ESM3/ABORT 属于测试 在原始测试中记录并正确处理。 积分器随后还可以"复制逻辑"进行故障注入测试、因为这是预期行为。

我在这里尝试询问这些诊断模式的实际作用是什么、 由于我不理解为什么这个 ESM3参加这个测试(仍然不理解它-但如果这是真正的副作用、也许我不需要理解它-只要知道 ESM3/ABORT 将被激活是有原因对我来说就足够了)、 当从 FIQ 返回时、Eesm3/abort 将会激活、并执行下一行代码-因此基本上在 FIQ 中执行的 C 代码不会导致该行为。 还想知道为什么 FIQ 中需要手动写入0x5400、因为应该存在"自动清除"DIAG_TRIG、但测试中根本没有设置 TRIG 位、即使 TRM 5.6.2表示如果 DIAG_TRIG 不是、也仍然会生成初始 esm2错误 设置... 但是、如果此测试的 ESM3/ABORT 功能"已确认"、我很可能也不需要了解这方面的详细信息... 只要我需要自己进行相当“繁重”的修改，我就想知道根本原因，因为通常如果你不理解根本原因，“修复”可能是完全错误的，即使它看起来是有效的，并且可能导致更灾难性的失败...
https://e2e.ti.com/support/microcontrollers/hercules/f/312/t/603175

//////////// 故障注入变体的更多信息
这里其他用户的 ESM3问题完全相同(在同一测试的故障注入变体中-我遇到了相同的问题、但由于找到了一种方法来"修复"实际测试、因此相同的步骤适用于故障注入变体)。 想知道为什么有人说测试运行不会出现问题、以防 ESM3出现上述状态的" IDE 影响问题"、或者此测试在不同的 CPU 型号上的工作方式不同、因为需要修改最低0x5400来防止连续 FIQ 环路、具体取决于 可能还需要0x5400位置设置手动 SR1 ACK、以便甚至达到 ESM3/ABORT 弹出的状态、因为至少在我的代码中、"辅助 FIQ"将被解释为真正的故障、因为"一次性消耗性 FI 标志"不再有效、因为它已经失效 在第1轮中清零、代码最终在 while (1)循环中？
https://e2e.ti.com/support/microcontrollers/hercules/f/312/t/608591

以下是我的故障注入版本体验(基本上、如果在 sl_ESM.c 中为该测试设置相同的0x5400、您就可以使用该版本 (或在应用程序端 ESM-ERROR 处理程序中执行此操作、但您需要手动将同时挂起的 FIQ 从 SR[1]中删除、因为它已自行恢复、如果没有手动恢复、则代码在退出后立即跳回到 FIQ) -我认为该0x5400的正确位置是 sl_ESM.c，因为这与测试有关，而不是实际的故障处理，如果这是真正的故障，则无需在应用程序端写入0x5400来处理故障，以防代码执行需要继续...
e2e.ti.com/.../2217778
-在 sl_sem．c 中设置0x5400之后，应用程序只需等待 ESM3错误弹出，并在处理实际测试时在应用程序端类似地处理它


////// 了解信息很好

平均时间我改进了数据中止屏蔽了这个帖子中代码的位(只是试图防止实际错误不被意外屏蔽掉、 因此、基本而言、每个屏蔽确定至少有2个"密钥"、需要进行匹配才能屏蔽数据中止、从而使其在发生单点故障时更可靠、并在进行测试时捕获可能的真实错误。 在写入0x5400值时、也可以在 sl_ESM.c 中设置一些标志、该值将在此处选中并清除、这样每次测试只允许一次屏蔽、但这需要修改 sl_ESM.c、这可能会在应用 CSP 时导致更多的手动工作)。

   //最初内容为 F021F_FPAROVR_ADD_INV_PAR|FPAROVR_TEST_EN，但在 FIQ 中断中切换内容
   if (((sl_FLAG_GET ((Int32) flash_address_parache_self_test)))&& DIAG_CHECks (F021F_FDCTRL_DMODE_TEST_MODE，0x5400U))
   ｛  //注意：JSI 14.6.2017：如果启用了 FIQ、此测试也会导致数据中止
       if (_sl_get_DataFault_Address ()= 0x20000000U)//设置一些屏障，而不仅仅是信任 sl_FLAG_GET_VALUE
       ｛
           maskDAbort = true；
       ｝
   ｝

这里是我针对故障注入变体的电流屏蔽逻辑(在 DIAG_vEsmAppCallback()内 )如果 tEsmFiCb.bFlashPar_2-flag 已经被清除、ESM3错误就会被删除)
   //最初内容为 F021F_FPAROVR_ADD_INV_PAR|FPAROVR_TEST_EN，但在 FIQ 中断中切换内容
   if (((sl_FLAG_GET ((Int32) FLASH_ADDRESS_奇 偶校验_FAULT_INPUT))& DIAG_CHECks (F021F_FDCTRL_DMODE_TEST_MODE，0x5400U))
   ｛  //注意：JSI 14.6.2017：如果启用了 FIQ、此测试也会导致数据中止
       if (_sl_get_DataFault_Address ()= 0x20000000U)//设置一些屏障，而不仅仅是信任 sl_FLAG_GET_VALUE
       ｛
           //这里是屏蔽的逻辑
           布尔 bFlashAddParCb = tEsmFib.bFlashPar_2；

           callbkParam1 = sl_flashWREG->FUNCHERRADD；
           callbkParam2 = sl_flashWREG->FEDACCSTATUS；
           uint32 u32Error = Set_HIWORD_U32 (ESM_Group_3)| Set_LOWORD_U32 (ESM_G3ERR_FMC_Uncorr)；
           DIAG_vEsmAppCallback (u32Error、callbkParam1、callbkParam2、callbkParam3)；

           if ((bFlashAddParCb)&&(！tEsmFib.bFlashPar_2))
           ｛
               maskDAbort = true；
           ｝
       ｝
   ｝

您好、Jarkko、

您在下面引述的回复中包含的注释。

[引用用户="Jarkko Silvasti"]

您好！

只是为了澄清：这是否意味着、在当前形式的代码中、如果启用了 FIQ、那么组3错误+中止是运行此测试的"实际且预期"副作用-而不是我一侧的某种编码错误？

根据代码的当前状态、我认为可以预期出现的异常和中断。 我不能说的是、如果这意味着测试运行正确、异常处理正确。 我们需要确定异常的根本原因、以确定是否可以避免异常、或者我们是否将其保留为测试的预期结果。 在我看来、这个测试是测试闪存地址奇偶校验特性、这是 ESM G2 CH4、并且不应该触发其它 ESM 错误或中止、但是、也许有一个逻辑原因尚未被识别。

如果这是真正的确定性副作用、我至少可以忍受该组3错误、因此我不需要从 RAM 运行代码来防止它发生或其他任何更复杂的事情-如果这种行为、我可以很容易地看到 ESM3/ABORT 属于测试 在原始测试中记录并正确处理。 积分器随后还可以"复制逻辑"进行故障注入测试、因为这是预期行为。

在您提到设置了哪个 G3通道标志的线程中、我看不到任何位置、但我假设它是指示不可纠正的闪存错误(2位或更多错误)的通道7。 这可能是由于闪存中可用于两个测试的某些共享位置造成的、但即使是这种情况、也不必要、因为读取的数据不必有数据错误来检查闪存地址奇偶校验。

我在这里尝试询问这些诊断模式的实际作用是什么、 由于我不理解为什么这个 ESM3参加这个测试(仍然不理解它-但如果这是真正的副作用、也许我不需要理解它-只要知道 ESM3/ABORT 将被激活是有原因对我来说就足够了)、 当从 FIQ 返回时、Eesm3/abort 将会激活、并执行下一行代码-因此基本上在 FIQ 中执行的 C 代码不会导致该行为。 还想知道为什么 FIQ 中需要手动写入0x5400、因为应该存在"自动清除"DIAG_TRIG、但测试中根本没有设置 TRIG 位、即使 TRM 5.6.2表示如果 DIAG_TRIG 不是、也仍然会生成初始 esm2错误 设置... 但是、如果此测试的 ESM3/ABORT 功能"已确认"、我很可能也不需要了解这方面的详细信息... 只要我需要自己进行相当“繁重”的修改，我就想知道根本原因，因为通常如果你不理解根本原因，“修复”可能是完全错误的，即使它看起来是有效的，并且可能导致更灾难性的失败...

https://e2e.ti.com/support/microcontrollers/hercules/f/312/t/603175

我同意在没有适当背景/背景的情况下进行修改可能会掩盖真正的问题或以某种方式挫败测试的预期用途。 这就是我们在此帮助扩展对测试的理解的原因。 当然、查看数据表和 ESM 错误类型会有所帮助、但并不能得出结论。 这些器件非常复杂、需要学习很多细节、并需要查看大量文档才能完全理解。 即使这样、文档中的含义有时也会丢失、没有实际的真实使用和示例。 我还没有机会详细查看您的链接帖子、但我计划查看每个帖子、以确保我们捕获 SafeTI Diag Lib (SDL)的问题。 因此、我们可以在下一个版本中包含尽可能多的修复程序、我们将尽可能地将 其纳入计划中、以满足您的项目要求。

//////////// 故障注入变体的更多信息
这里其他用户的 ESM3问题完全相同(在同一测试的故障注入变体中-我遇到了相同的问题、但由于找到了一种方法来"修复"实际测试、因此相同的步骤适用于故障注入变体)。 想知道为什么有人说测试运行不会出现问题、以防 ESM3出现上述状态的" IDE 影响问题"、或者此测试在不同的 CPU 型号上的工作方式不同、因为需要修改最低0x5400来防止连续 FIQ 环路、具体取决于 可能还需要0x5400位置设置手动 SR1 ACK、以便甚至达到 ESM3/ABORT 弹出的状态、因为至少在我的代码中、"辅助 FIQ"将被解释为真正的故障、因为"一次性消耗性 FI 标志"不再有效、因为它已经失效 在第1轮中清零、代码最终在 while (1)循环中？
https://e2e.ti.com/support/microcontrollers/hercules/f/312/t/608591

以下是我的故障注入版本体验(基本上、如果在 sl_ESM.c 中为该测试设置相同的0x5400、您就可以使用该版本 (或在应用程序端 ESM-ERROR 处理程序中执行此操作、但您需要手动将同时挂起的 FIQ 从 SR[1]中删除、因为它已自行恢复、如果没有手动恢复、则代码在退出后立即跳回到 FIQ) -我认为该0x5400的正确位置是 sl_ESM.c，因为这与测试有关，而不是实际的故障处理，如果这是真正的故障，则无需在应用程序端写入0x5400来处理故障，以防代码执行需要继续...
e2e.ti.com/.../2217778
-在 sl_sem．c 中设置0x5400之后，应用程序只需等待 ESM3错误弹出，并在处理实际测试时在应用程序端类似地处理它

对于故障注入模式的实际用途、我仍然有点困惑。 当然、如果系统级通知正确到位、它可用于测试错误路径和处理、但我最初的理解是、它将用作最终用户开发其安全系统时进行验证的工具。 即、它可用于描述错误响应。 我不确定每个测试都需要包含 FI 测试、也许只能考虑基本元素。 但是、这取决于系统级要求、我们依赖于终端应用集成商对如何使用提供的软件的经验和判断。

////// 了解信息很好

平均时间我改进了数据中止屏蔽了这个帖子中代码的位(只是试图防止实际错误不被意外屏蔽掉、 因此、基本而言、每个屏蔽确定至少有2个"密钥"、需要进行匹配才能屏蔽数据中止、从而使其在发生单点故障时更可靠、并在进行测试时捕获可能的真实错误。 在写入0x5400值时、也可以在 sl_ESM.c 中设置一些标志、该值将在此处选中并清除、这样每次测试只允许一次屏蔽、但这需要修改 sl_ESM.c、这可能会在应用 CSP 时导致更多的手动工作)。

   //最初内容为 F021F_FPAROVR_ADD_INV_PAR|FPAROVR_TEST_EN，但在 FIQ 中断中切换内容
   if (((sl_FLAG_GET ((Int32) flash_address_parache_self_test)))&& DIAG_CHECks (F021F_FDCTRL_DMODE_TEST_MODE，0x5400U))
   ｛  //注意：JSI 14.6.2017：如果启用了 FIQ、此测试也会导致数据中止
       if (_sl_get_DataFault_Address ()= 0x20000000U)//设置一些屏障，而不仅仅是信任 sl_FLAG_GET_VALUE
       ｛
           maskDAbort = true；
       ｝
   ｝

这里是我针对故障注入变体的电流屏蔽逻辑(在 DIAG_vEsmAppCallback()内 )如果 tEsmFiCb.bFlashPar_2-flag 已经被清除、ESM3错误就会被删除)
   //最初内容为 F021F_FPAROVR_ADD_INV_PAR|FPAROVR_TEST_EN，但在 FIQ 中断中切换内容
   if (((sl_FLAG_GET ((Int32) FLASH_ADDRESS_奇 偶校验_FAULT_INPUT))& DIAG_CHECks (F021F_FDCTRL_DMODE_TEST_MODE，0x5400U))
   ｛  //注意：JSI 14.6.2017：如果启用了 FIQ、此测试也会导致数据中止
       if (_sl_get_DataFault_Address ()= 0x20000000U)//设置一些屏障，而不仅仅是信任 sl_FLAG_GET_VALUE
       ｛
           //这里是屏蔽的逻辑
           布尔 bFlashAddParCb = tEsmFib.bFlashPar_2；

           callbkParam1 = sl_flashWREG->FUNCHERRADD；
           callbkParam2 = sl_flashWREG->FEDACCSTATUS；
           uint32 u32Error = Set_HIWORD_U32 (ESM_Group_3)| Set_LOWORD_U32 (ESM_G3ERR_FMC_Uncorr)；
           DIAG_vEsmAppCallback (u32Error、callbkParam1、callbkParam2、callbkParam3)；

           if ((bFlashAddParCb)&&(！tEsmFib.bFlashPar_2))
           ｛
               maskDAbort = true；
           ｝
       ｝
   ｝

[/报价]

您好！

我是在度假，这就是为什么延迟答复的原因。

是的、它会将 ESM 通道位与已猜中的中止一起升高、即编号7 "ESM_G3ERR_FMC_Uncorr"。


是的、我们目前使用的是 SafeTI 版本2.3.1。


由于我听说新版本即将推出、我想它会显示此测试的状态吗？ 我不介意、如果您可以在这里告诉您、将来它只会发出预期组2错误或该组3错误的信号、以及该组3错误的原因是什么/是什么、原因是什么是它出现/出现-只是为了提高我自己对器件的理解、 从我的中止处理程序代码中可以看到、违规地址是0x20000000、它是镜像闪存、根据该代码应该包含1位错误、#define flashBadECC1 0x20000000u？


我想这有点偏离主题、但尝试回答您提出/提到/想问的问题：

我认为、实际 SafeTI 测试对应的故障插入测试应在产品开发期间至少运行一次、可能在代码中带有条件编译标志、以便测试系统是否能够对故障做出反应。 我选择在运行时与常规测试一起运行它们、因为实际上、在构建测试线束时、执行此操作所需的工作量非常小(并且比手动运行更具成本效益)。 但正如您所说的，这是积分器确定何时/如何运行它们的问题，有些积分器可能根本不运行它们，它可能仍然是任何其他方法的有效方法：)... 我习惯做一点"额外"、只是为了确保、而不是用几乎相同的时间来解释为什么不需要这样做。


对于 CSP、我们的最初意图是"按原样"使用此 SafeTI 库代码、然后使用这些文档、以最大限度地缩短与认证相关的工作时间(如果需要、还可能运行 LDRA 测试)、 但是、在当前的形式中、直接方法似乎是不可能的、因为需要对 SafeTI 代码进行一些(不多)手动更改、因此在任何情况下都需要进行一些额外的手动工作。 让我们看看是否希望新发布的版本会改变这种情况、并且代码可以按原样使用。 更好的是、如果免费收到用于"认证"的文档、因为如果2.3.1正确理解、即使不使用 LDRA、您仍需要购买该 CSP 才能获取文档？

根据您的评论、即将发布的版本将不包含文档(免费)、如果它将仅声明 CCStudio 的状态库设置、用户可以使用它编译库、然后在 IAR 中使用它？ 使用未经修改的库当然是最简单的方法(在任何情况下都是首选方法)、但让我们看看这是否可行。 这种与免费文档捆绑在一起的方式也将具有成本效益和时间效益、如果可能的话、我们很可能会选择这种方式。

整个"如何认证"概念对我们来说仍然有点开放/模糊、因为我们之前仅使用了自己的代码、即已准备好的认证代码和第三方代码、这些代码没有任何预先制作的安全资料。 因此、这种采用 CSP 的第三方代码对我们来说是新代码、这就是为什么我无法说出我们最终如何"认证"的原因、但我们认为、从现在开始、我们一直在获得执行所需的 SafeTI 测试以及整个产品(我们的、而不是 SafeTI) 因为之前没有任何需要证明的东西... 尤其有雾的是、如果我们需要对 CSP 代码进行1行更改、那么该怎么办、只需将文档用于其余代码、例如、使用审阅来证明更改的正确性和/或基于自己或 LDRA (如果购买了该封装) 已更改零件的单位测试。 我们还计划制作基于 RM44的产品、以便在您能够与特定认证流程取得一定的协同增效时、这可能是进行此操作的最佳方式、同时还请记住、现有产品可能会收到更新、该更新会在板上获取新的 SafeTI 项目(测试)...

如果你有这方面的建议，我愿意倾听，尽管我没有作出与金钱有关的决定：)。

[引用用户="Chuck Davenport"]

我认为、您使用的是与 TI 编译器不同的经过认证的编译器、该编译器经过认证并用于构建经 TI 测试的代码、 即使您未修改代码、这些报告也不适用、然后您需要使用 TAU 工具对生成的二进制文件进行回归测试。
只需继续这个"非主题"、如果我错了、请纠正我的错误、但我已经假设应该可以使用 TI 工具编译库、然后在 IAR 中使用该库？ 这样、我们应该能够使用准确指定的编译器版本和设置(即使我们需要对代码进行更改、例如仅对1个函数进行更改、否则其余未修改的代码将直接符合您的测试文档)。

您好、Jarkko、

[引用用户="Jarkko Silvasti">要继续此"非主题"、请更正我、以防我出错、但我假设应该可以使用 TI 工具编译库、然后在 IAR 中使用该库？ 这样、我们就应该能够使用准确指定的编译器版本和设置(即使我们需要对代码进行更改、例如仅对1个函数进行更改、否则其余未修改的代码将直接符合您的测试文档)。

当然可以。 此外、如果您以这种方式接近项目、如果您修改代码的案例非常有限、则可以像为项目编写的任何其他代码那样开发自己的测试/计划。 即、遵循您自己的软件开发流程、该流程符合安全标准、有助于避免从 LDRA 和我们的软件团队购买 Tau 工具。