ISO 26262项目的裁剪工作到底要怎么开展，还有裁剪的理由又要怎样去说明，这件事情在功能安全相关的项目里面，它的重要性其实是经常被低估的，项目刚刚开始启动的时候，有的团队习惯于把标准里的那些条款，全部给塞进计划书当中，结果文档是越做越厚，可真到了要去执行的时候，团队成员却抓不住真正的重点；也有的团队为了赶一赶项目的进度，就把那些自己不想做的内容，直接给写成了不适用，可是等到后来客户评审、功能安全审核，或者是量产前再进行复盘的时候，大家就很容易陷入解释不清的麻烦了，项目裁剪这件事的目的，就是在不会削弱安全目标这个大前提下，把那些需要去做的工作、可以合并到一起的活动、能够拿来复用的证据，还有并不适用的条款，都给说清楚。

　　一、ISO 26262项目裁剪怎么开展

　　要对ISO 26262的项目进行裁剪，不能一上来就从删减文档开始，而是要先从项目的边界、产品的形态，还有安全的目标这几个地方入手，只有先把项目到底涉及哪些系统、哪些功能、哪些变更给弄清楚了，后面才能去判断，哪些活动是必须保留下来的，哪些内容是可以被简化的。

　　1、先确认项目的范围

　　在项目刚刚启动的那个时候，项目组就需要把产品对象、开发阶段、涉及到的模块、硬件和软件的边界、供应商的分工，还有客户提出的要求，都一一整理出来，比方说，这到底是一个全新平台的开发，还是在已有平台上做的小改型；是要做一个整车级别的功能，还是只做单个电子控制单元；是要进行完整的开发，还是只是去做软件配置上的变更，这些不同的情况，它们对应的工作量，差别是非常大的。

　　2、再确认安全目标和安全完整性等级

　　做裁剪的时候，是不能脱离危害分析和风险评估得到的结果的，安全的目标、安全完整性等级的划分、故障发生的场景、暴露出来的概率，还有可控制性，这些因素都会影响到后面活动的安排，对于那些安全完整性等级比较高的内容，通常就需要去做更加完整的分析、验证和确认工作；而对于那些低风险的，或者是跟安全不相关的内容，则可以在有充分依据的情况下，去减少一些投入，但是这么做的理由，一定要写得很清楚。

　　3、梳理标准活动的清单

　　接下来，就要把概念阶段、系统开发、硬件开发、软件开发、生产运行、确认措施等等这些活动，都给列出来，然后再一项一项地去判断，它们对于当前的这个项目到底是不是适用，这个时候，不要只是简单地写上“保留”或者“不适用”，而是要把这样判断的依据给说明清楚，举个例子来说，如果项目并没有涉及到硬件设计的变更，那么关于硬件详细设计的那些活动，就可以去引用已经存在的证据，但是关于接口影响的分析，却仍然还是需要被保留下来的。

　　4、识别可以复用的内容

　　在很多项目里，工作并不是从零开始的，可能已经有了一些安全概念、架构设计、测试报告、工具评估的记录，还有生产控制的文件，当我们去复用这些现成材料的时候，需要检查一下它们的版本、适用的范围、跟当前情况存在哪些变更上的差异，以及还有哪些遗留的问题，不能只是因为这个东西以前做过，就直接把它拿过来用，那些被复用的内容，必须能够对应得上当前的安全目标，还有当前产品的状态。

　　5、形成裁剪的矩阵

　　裁剪得到的结果，我们最好是把它整理成一个矩阵的样子，里面的内容要包括标准的活动、适用的结论、保留的方式、简化的方式、责任人是谁、有哪些输入的文件、输出的证据，还有对应的理由说明，这样一来，到了后面进行评审的时候，别人就能看清楚每一项活动为什么要做、具体要怎么做、要做到什么样的程度，而不会只看到一份零零散散的说明。

　　二、ISO 26262项目裁剪理由怎么说明

　　ISO 26262项目裁剪的理由，是需要经得住别人不断追问的，不能把它写成像是“项目周期太紧了”“客户暂时没有要求”“历史项目已经做完了”这一类含糊的说法，裁剪的理由，它本质上是在向别人说明，风险为什么还是被控制住的，安全的目标又为什么没有被降低。

　　1、要用项目里的事实来做说明

　　理由需要和项目中的具体事实绑在一起，举个例子，这一次我们只是修改了诊断的阈值，并没有去改变安全的机制、硬件的接口，还有控制的策略，所以，系统架构的分析就可以继续沿用原来的既有版本，只需要再去补充一份变更影响的分析，还有回归测试的记录就可以了，像这样的写法，是有边界、有依据的，比简简单单地写上一句“没有重大变更”，要更容易被评审给通过。

　　2、要用安全完整性等级的影响来做说明

　　如果项目组把某一项活动给简化了，那就需要讲清楚，它是不是会影响到安全目标，还有安全完整性等级的分解情况，比如，对于一个不涉及安全的接口界面做了调整，我们就可以说明，这个变更并不参与安全机制，也不会改变故障被检测出来的路径，同时还不影响安全状态进入的逻辑，来做评审的那些人，他们真正关心的，并不是我们少做了什么，而是在少了这些动作之后，风险到底还能不能被控制得住。

　　3、要用已有的证据来做支撑

　　裁剪的理由，不能仅仅只靠文字上的判断来支撑，我们可以去引用那些已有的安全分析、测试报告、验证记录、配置清单、变更评审的记录，还有供应商交付过来的资料，在引用它们的时候，需要写清楚文件的名称、版本，还有适用的范围，这么做可以避免到了评审的时候，被别人发现我们引用的其实是旧的版本，或者文件所覆盖的对象，跟当前这个项目是对不上的。

　　4、要把限制的条件写清楚

　　有些裁剪的决定，只有在特定的条件底下，才是成立的，比如说，它只限于当前的软件版本、只限于现有的硬件平台、只限于原来那家供应商提供的器件，或者只限于已经存在的生产流程，一旦这些条件发生了变化，那么裁剪得到的结论，也需要被重新评估一遍，我们把这些限制的条件提前写出来，表面上看着是麻烦了一点，可实际上，它能减少项目后期很多不必要的争论。

　　5、要对补偿的措施做出说明

　　某些活动在被简化了之后，是可以用一些补偿的措施，来把风险给兜住的，比如，我们决定不再重新去做完整的系统测试了，但是会增加变更影响范围内的回归测试；不重新去开展完整的供应商审核了，但是会要求供应商把他们更新后的符合性声明，还有那些关键的测试记录给提交过来，这些被提出来的补偿措施，要能够跟那些被简化掉的活动对应得上，不能随随便便就写一条培训或者开会的记录，去把它给替代掉。

　　三、ISO 26262项目裁剪记录怎么留存

　　当ISO 26262项目的裁剪工作都做完了以后，把痕迹留下来，是比口头上的解释要重要得多的，客户来进行审核的时候，他们通常不会只问问你当时是怎么想的，而是会顺着留下来的那些记录，去看你的依据是什么、经过了谁的审批，还有最后执行出来是个什么样的结果。

　　1、保存裁剪决策的记录

　　我们要把裁剪的矩阵、会议的纪要、评审的意见、责任人的确认，还有批准的那些记录，都给保留下来，特别是那些被判定成不适用，或者是要简化去执行的活动，需要让别人能够看到，是谁提出来的、是谁评审的、又是谁批准的，还有那个时候所依据的，到底是什么。

　　2、保留变更影响的分析

　　当项目进行到一半的时候，如果发生了需求上的变化、设计上的调整、供应商被替换掉，或者是测试的结果出现了异常，这个时候，就需要重新去检查一下，当初裁剪得到的那些结论，是不是还能够成立，变更影响的分析，是要和裁剪的记录关联在一起的，不要出现前面刚说过不涉及某一项活动，可后面发生的变更明明已经影响到了这个范围，却没有去重新评估的情况。

　　3、把证据放到可以被追溯的位置

　　裁剪所依据的那些材料，不能散落在个人的电脑里、聊天的记录里，或者是临时的文件夹里面，我们最好是把它们放在项目的配置库里，按照安全计划、分析报告、设计文件、验证记录、评审记录这些类别，去进行分类管理，文件的版本需要是清楚的，引用的路径也要是稳定的，这样，后续来做审核的人，才能顺着我们留下的线索，查找到完整的证据。

　　4、在关闭阶段复核裁剪的执行情况

　　到了项目快要收尾的时候，我们还要再去检查一下，这份裁剪的计划是不是真的被落实到位了，那些被保留下来的活动，有没有都完成；那些被简化了的活动，有没有补充上相应的证据；那些当初被判定为不适用的活动，有没有出现什么新的、让它变得适用的条件，这个复核的动作，是能够避免在项目早期的时候，裁剪方案写得很漂亮，可是到了最后执行的时候，却跟计划完全脱了节。

　　总结

　　总得来说，ISO 26262项目的裁剪要怎么去开展，裁剪的理由又要怎么去说明，这里面最关键的一点，是要把项目的边界、安全完整性等级带来的影响、变更的范围、证据的复用，还有那些限制的条件，都给讲清楚，裁剪这件事情，并不是在让大家少做工作，也不是要去把标准里的条款给删掉，它的目的，是要让那些和安全相关的活动，能够被做得更加贴合项目的实际情况，只要我们把裁剪的矩阵做完整了，把理由写具体了，让证据都可以被追溯得到，并且在变更发生以后能够重新去做评估，那么这个项目到了评审和交付的那个阶段，也就更容易把话说清楚，把脚跟站稳了。