MUNIK解读ISO26262：功能安全之工具鉴定
—原创文章，文章内所有内容文字资料，版权均属本公司所有，任何媒体、网站、公众号或个人未经本公司授权不得转载、转贴、引用或以其他方式复制发布 、发表。已经本公司授权的媒体、网站、公众号、个人，在下载使用时必须注明来源，违者本公众号将依法追究相关责任.
回到本文的源头文章“ISO26262标准解读”，请点击链接：ISO26262 Functional Safety of Automotive汽车功能安全服务
回到知识分享，请点击链接：MUNIK中国-技术分享
功能安全项目不可避免会使用到各种类型的软件工具，包括管理类软件工具、开发类软件工具、测试类软件工具以及评审类软件工具等等。如果这些软件工具自身有一些漏洞，导致项目中某些安全目标被影响，此结果是我们不希望看到的，这时就需要进行软件工具的置信度水平评估以及鉴定活动了。
下图是软件工具置信度活动的介绍
图中我们可以简单了解到，软件工具置信度的水平需要经过评估与鉴定两个环节来完成，评估的目的是用来筛选哪些软件工具需要执行软件工具鉴定活动以防止安全目标的违背。具体的评估与鉴定活动流程可以参考下图：
评估的标准从两方面考虑，一个是工具造成的影响（TI），另一个是工具错误探测（TD）。
a) 特定软件工具功能异常可引入或不能探测开发中安全相关项或要素中错误的可能性。这是通过工具影响（TI）等级表示的：
l 当有论据表明没有这样的可能性时，应选择TI1；
l 其他情况下应选择TI2。
原文解释：软件工具不可能引入功能安全异常，或软件工具不可能出现无法探测与安全相关错误的情况，此时应当选择TI1，否则选择TI2。
示例：功能安全项目中应用到的软件工具有Allegro、Proteus、Visio等
l 其中Visio属于TI1等级，因为当Visio工具出现异常时，仅会影响到项目中各类图示信息，并不违反安全要求
l Allegro、Proteus属于TI2等级，当软件工具出现异常时，有可能直接导致安全要求的违反，例如产品电路的设计异常、不正确的仿真结果结果未被指出等
b) 用于预防软件工具功能异常并产生相应错误输出的措施的置信度，或用于探测软件工具存在功能异常并已经产生相应错误输出的措施的置信度。这是通过工具错误探测（TD）等级表示的：
l 当对预防或探测出功能异常及其相应错误输出具有高置信度时，应选择TD1；
l 当对预防或探测出功能异常及其相应错误输出具有中等置信度时，应选择TD2；
l 在所有其他情况下应选择TD3。
原文解释：使用了某些措施来预防软件工具的失效或错误输出（例如同类型软件工具输出结果对比等），或使用某些措施探测该软件工具是否正常实现功能（例如用已知的输入输出数据集合来验证软件工具工作状态等）。
示例：功能安全项目中应用到的软件工具有C++、MS Project、EXCEL等
l 其中MS Project属于TD1等级，因为当MS Project工具的使用过程中是多人审阅与抄送的，即使出现异常也会有多环节的验证审批过程，体现了软件工具的高置信度。
l C++属于TD2等级，当软件工具出现异常时，仅依靠软件工程师对编码结果核查，置信度略低
l EXCEL属于TD3等级，在植入公式的表格中对各项数据进行运算，没有相应预防措施
当软件工具置信度等级不满足TCL1时，需要执行软件工具鉴定活动
标准中对TCL2、TCL3等级置信度的软件工具鉴定活动做了如下图的要求：
可以看到不同的ASIL等级推荐的鉴定方法是不一样的，如何选择合适的鉴定方法就是要关注的内容。一方面是要考虑企业能否满足该鉴定方法的执行条件，另一方面还要考虑该方法是否满足在当下ASIL等级下功能安全的要求等。
一般来说，常用的鉴定方法一个是使用中积累置信度，另一个是委托第三方鉴定机构对软件工具进行鉴定。
如果企业的数据库有足够的数据支撑来证明软件工具的失效率是足够低的或没有失效的结果发生，那么可以通过此数据来作为软件工具置信度的依据。还有就是委托知名的第三方软件工具鉴定机构，使用高覆盖的Test Case对软件工具进行测试，最终出具符合要求的鉴定报告。
使用中积累置信度示例：
某软件工具的作用是芯片RTL逻辑验证，在项目开发过程中均会使用到此软件工具。此时企业内部数据中有对RTL代码编辑异常的记录程序，在这个记录单中会详细描述RTL由于什么因素导致编辑异常。此时，可以筛选出由于验证导致的异常，判断是否是工具引起还是人员操作失误导致。最终工具引起的异常数占所有RTL编辑任务总数的占比就可以得出工具置信度的数据。
工具鉴定的另一种选择是通过在使用软件工具的产品开发过程中引入额外的措施来增加检测错误
工具输出的可能性。这将把工具错误探测等级降低到TD1，可以避免进入工具鉴定的环节。
当然最优的做法，就是我们在项目开始阶段就选定已经通过功能安全认证的软件工具，这样就可以省略掉繁琐的评估鉴定工作。
最后再强调一点，软件工具的评估与鉴定活动应当在项目初期完成，至少在开发阶段之前，以免影响后续开发活动输出物的有效性，延长项目进度。
