在功能安全相关的项目里，有一件事的重要性经常被低估，那就是ISO 26262当中工具置信度该怎么去判定，以及为了证明这个置信度，相关的证据又要怎么去准备，很多项目团队，在一开始的时候，注意力往往只放在工具到底能不能用，还有它能不能顺利地导出报告上面，一直要等到客户来评审，或者是安全审核的时候，才会突然意识到，工具本身其实也是需要去说明，它到底有多可信的，工具置信度这件事，并不是简单地给工具贴上一个“可靠”的标签就行了，它是要去证明，这个工具在项目里的使用方式、它失效后会带来的影响、对它进行验证的手段，还有过往已经积累下来的使用经验，这几样东西都是能够讲得通的，在做这个判定的时候，我们不能脱离具体的项目去空谈，也不能把供应商给过来的材料，直接当成了完整的证据来用。
一、ISO 26262工具置信度怎么判定
要去判定ISO 26262的工具置信度，首先要看的，是这个工具在安全的生命周期里面，究竟承担了什么样的角色，不同工具所面临的风险，是完全不一样的，像需求管理的工具、建模的工具、代码生成的工具、静态分析的工具、测试管理的工具，还有配置管理的工具，这些是不能够用同一套标准去简单地处理的。
1、先把工具的用途给明确下来
我们首先需要写清楚，这个工具是用在哪一个活动上的，比如是用来做需求的追踪、模型的设计、代码的生成、测试的执行、缺陷的管理、静态的检查，还是文档的生成，如果工具只是帮着去查看一些信息，跟工具直接生成和安全相关的输出，这两者对于置信度的要求，显然是不同的，如果用途都写不清楚，那么后面的影响分析，就会变得飘忽不定。
2、去判断工具一旦出错，会造成什么样的影响
在做工具置信度判断的时候，要去看看，工具一旦出了错，它是不是有可能引入新的错误，或者说，它是不是有可能让那些已经存在的错误被漏掉，就比如，代码生成工具如果生成了错误的代码，它是有可能直接影响到软件的实现本身的；测试管理的工具如果漏记了测试的结果，那就可能影响到最后验证出来的结论；而格式转换的工具如果只是把文档的编号给弄乱了，通常来说，它的风险就要低一些，在这里，我们需要把错误带来的影响给说清楚，而不能仅仅是写上一句“工具异常”就完了。
3、去看这些错误，到底能不能被发现
如果在工具的输出来出来之后，后面还有人工的评审、交叉的检查、编译的验证、单元的测试、集成的测试这些环节，那么工具所犯的错误，被发现的几率就会高一些；反过来，要是工具的输出，是直接就进入到了后续要交付的东西里面，而且还没有独立的检查环节，那风险自然就会升高了，在做判断的时候，要把这些检查的环节都给写出来，不能只是说一句“后续会审核”就带过去了。
4、要结合安全完整性等级和项目所在的场景来做判断
对工具置信度的判断，不能只盯着工具的名字去看，还要把它所参与的安全目标，还有对应的安全完整性等级给结合起来看，同一个工具，如果是在质量管理体系的范围里面使用，跟把它用在相关安全完整性等级比较高的工作产品里面，对证据的压力，是完全不一样的，项目组需要按照实际的用途去做出判断，不能把别的项目得出来的结论，原封不动地就搬过来用。
二、ISO 26262工具置信度证据怎么准备
准备ISO 26262工具置信度的证据，一个关键的重点，是要让来做审核的人，能够顺着你给出的这些材料，一步一步地看明白：为什么这个工具，是可以用在当前这个项目里面的，它一旦出了错以后会是一个什么情况，还有就是，项目组到底用了什么样的方式，去把那个风险给降下来的，这些证据，并不一定都需要弄得很厚，但是它一定要能够对应得上前面你做判断的那一套逻辑。
1、去准备一份工具的清单和关于它用途的说明
我们先要去建立一份工具的清单，在这份清单里面，要把工具的名称、版本号、供应商是谁、装在了一个什么样的环境里面、使用的部门、用在了哪些活动上、输出物的类型是什么，还有项目的范围，都给写清楚，版本号这个地方，是不能够漏掉的，因为当工具升级了之后，以前对它做验证的那些记录，可能就不再完全适用了，这份工具的清单，它是后面所有证据的一个入口，你写得越是清楚，评审的时候，别人追问的次数，往往就会越少。
2、去准备一份关于工具影响的分析
对于每一个相关的工具，我们都需要去说明，它存在哪些潜在的错误模式，以及这些错误会通过什么路径去产生影响，比如，“静态分析工具如果漏报了问题，可能会导致一些编码规则的违反项没有被发现”，或者“需求管理工具的链接如果丢掉了，可能会导致从需求到测试之间的追踪关系变得不完整”，在做影响分析的时候，不要把它写成那种很空泛的风险，而是要紧紧地贴着工具它实际的功能来写。
3、去把用来探测错误的那些措施给准备好
在关于工具的证据里面，是要写清楚，那些错误到底是怎么被发现的，比较常见的证据有，人工复核的记录、抽样检查的记录、回归测试的记录、用独立工具做交叉验证的记录、脚本输出比对的记录，还有评审会议的纪要等等，光是写上一句“人工检查”，这是不够的，我们最好能去说明，到底要检查一些什么、由谁来负责检查，还有检查完了之后，那个结果是在哪里留下了痕迹的。
4、去把供应商的材料和项目内部自己的材料都给准备好
供应商给过来的那些认证的证书、工具的合格包、用户的手册、发布的说明、已知问题的清单，还有验证的报告，这些东西，都是可以拿来当作证据用的，但是，项目组自己这边，还需要再去补充一些内部使用的记录，比方说，关于安装版本的确认、配置的说明、试运行的结果，还有对工具输出进行抽查的记录，供应商的材料，是用来证明这个工具它基础的能力的，而项目组自己的材料，是在证明它在这个具体的项目里面，是被正确地去使用了。
三、ISO 26262工具置信度怎样避免证据失控
围绕ISO 26262工具置信度开展的这些工作，是很容易走向两个极端的，一个极端是，只收上来几份供应商给的文件，就觉得这件事做完了；另一个极端是，把每一个哪怕很小很小的工具，都做成一套非常厚的证明包，前者，到了评审的时候是站不住脚的，而后者，又会把整个项目的进度给拖慢，一种更加可行的办法是，按照风险的高低，去分层次地准备证据。
1、把工具按照它影响的程度，分成不同的层次
对于那些对安全相关输出有直接影响的工具，我们要重点地去准备它的影响分析、验证的记录，还有使用上的限制；而对于那些只是用来做文档编辑、格式整理，或者信息查看的工具，对它们的说明，就可以适当地简化一些，分完了层次以后，团队的精力，才能被放到那些真正会影响到安全论证的工具上面去。
2、不要遗漏掉工具的配置情况
有些工具，它本身是没有什么问题的，真正出了问题的，其实是它的配置，比如说，静态分析的规则集没有被启用、代码生成的选项被人改动过、测试脚本的参数前后不一致，这些情况，都是有可能影响到结果的可信度的，在证据里面，我们需要把那些关键的配置截图、配置文件的版本、审批的记录，或者是基线的记录，都给保留下来。
3、把工具的证据接到安全的档案里面去
关于工具置信度的那些证据，是不能够散落在个人的电脑上，或者一些临时的文件夹里面的，它应该跟安全计划、验证计划、配置管理的计划，还有安全的档案，形成一个能够对应上的关系，当审核的人追到某一个具体工具的时候，他能够从清单那里看到影响的分析，然后再顺着看到验证的证据，还有版本的记录，这一整条线索，是要能够连得上的。
4、当工具发生变更之后，要及时地重新去做判断
工具进行了升级、插件被替换掉了、许可证的版本发生了变化、或者是运行的环境改变了，这些变动，都是有可能会影响到我们原来对置信度所做的判断的，不要一直等到项目快要结束的时候，才去补这些材料，在变更发生的那一个时间点，我们就要去确认，是不是需要重新去做验证、重新去做抽查，或者是去更新那些证据，这个动作做起来虽然看着是麻烦了一点，但是比起在审核前手忙脚乱地去集中补证据，是要稳当得多的。
总结
总地来说，ISO 26262工具置信度要怎么去判定，还有它的证据又要怎么去准备，这里面的重点，并不是要把工具给描述得有多么多么的可靠，而是要把这个工具在项目里所起的作用、它潜在可能发生的错误、能够发现这些错误的手段，还有一整条证据链，都给说得明明白白，在做判定的时候，我们先去看它的用途，然后再去看它出错的影响，以及被探测到的能力，准备证据的时候，则是要围绕着工具的清单、影响的分析、验证的记录、供应商的材料，还有项目组自己使用的记录，这几块来展开，只要我们所准备的证据，能够撑得起当前这个项目的使用场景，那么工具置信度这项工作，就不会变成一堆很难维护的、走形式用的材料。
