在功能安全项目快要进入量产或者刚刚量产的阶段，常常会碰到这样一个情况，流程文件里面写得明明很完整，可一旦到了真正要执行的时候，却变成了安全经理自己一个人在不停地催文档、追问题、补证据，所以，要把ISO 26262的安全文化真正落地，靠的并不是喊几句口号，而是要让项目里面的每一个角色，都清楚地知道自己应该去做什么、在什么时间点去做，还有做了以后要留下什么样的记录。

　　一、ISO 26262安全文化怎么落地

　　想要把ISO 26262的安全文化给落到实处，首先要做的事情，就是把它变成项目里面一个个具体看得到的动作，公司层面当然可以有一套统一的制度，但是在项目的现场，大家更需要的是一些能看得见的要求，比方说，评审到底要怎么去开，问题出来了要怎么往上报，变更又是依据什么来做出判断，证据最后要怎么去归档。

　　1、把安全的要求放到项目的启动阶段里去

　　在项目刚刚启动的时候，我们就要把功能安全的目标、对应的安全完整性等级、适用的范围、做了哪些裁剪以及它的理由，还有那些关键的交付物，都给明确下来，不要等到开发工作都已经做到一半了，才急急忙忙地去补那份安全计划，不然的话，到了后面，每一个团队都会觉得，功能安全是凭空多出来的一项额外工作，在项目启动的会议里面，就应该把这些安全活动、它们的责任人，还有时间上的节点，都给讲得清清楚楚，并且要形成一份正式的会议记录。

　　2、把安全的评审嵌入到开发的各个节点里面去

　　安全的文化，是不能靠着在项目快结束之前，大家集中起来补一堆评审材料来建立的，在需求的评审、架构的评审、设计的评审、测试的评审，还有最终放行的评审里面，我们都需要把与功能安全相关的检查项给加进去，比如说，需求是不是都可以被追溯得到，安全机制到底有没有被验证过，那些异常的工况是不是都被覆盖到了，还有发生的变更，是不是有可能会影响到最初定下来的安全目标。

　　3、建立一套问题升级的机制

　　关于功能安全的问题，不能只是让它停留在邮件你来我往的沟通里面，一旦发现了跟安全相关的风险，我们就应该去明确这个问题的等级、由哪个部门来负责、要在什么时间点被关闭掉，还有如果解决不了，要按照什么路径往上升级，特别是那些涉及到安全目标、技术安全概念、验证失败了，或者是跟量产变更有关的事情，都要被拿到项目的例会或者安全委员会上去讨论，不能靠着个人的判断，就把问题给压下去了。

　　4、把证据的管理纳入到日常的工作当中去

　　安全文化落地的最后，终究是一定会体现在各种各样的证据上面的，像安全计划、危害分析与风险评估、功能安全概念、技术安全概念、软件的安全需求、测试的报告、确认的措施，还有变更的记录，这些东西都要有自己明确的版本，还有经过审批留下的痕迹，如果平时不注意把这些证据留下来，等到审核之前，再急急忙忙地去补材料，就非常容易出现各个材料之间前后说法对不上的情况。

　　二、ISO 26262安全文化职责怎么分工

　　在做ISO 26262安全文化职责分工的时候，我们要让管理层、项目经理、安全经理、开发的人员、测试的人员，还有质量的人员，在这个里面，都有自己明确的一个位置，一旦分工不清楚，项目里就会很容易出现一个误区，觉得所有的功能安全，都应该是安全经理一个人去负责的事情。

　　1、管理层负责的是资源和大的原则

　　管理层要去负责制定安全的政策、搭建组织的结构、确保人员的能力、提供工具的资源，还要安排好工作的独立性，比如说，安全经理的手里是不是有足够的权限，去把风险给提出来；来做评审的那些人，是不是具备了足够的经验；当项目的进度和安全的要求起了冲突的时候，应该由谁来做最终的决策，这些，都是需要管理层提前去定下来的。

　　2、项目经理负责的是计划和整体的推进

　　项目经理不一定需要亲自去编写所有的安全文档，但是他需要把功能安全的活动，都纳入到整个项目的计划里面去，哪些关键的节点要提交失效模式和影响分析、故障树分析、测试的报告，哪些问题会影响到最终产品的释放，还有哪些变更需要重新去走一遍评估的流程，这些都应该在项目的计划里面被体现出来，如果一个项目经理只是盯着进度看，却不怎么关心安全的闭环情况，到了项目的后期，就很容易被审核这件事情给卡住。

　　3、功能安全经理负责的是方法和监督

　　功能安全经理这个角色，最主要的职责是负责安全计划的制定、方法的指导、对裁剪做出判断、审核的协调，还有对安全问题进行持续的跟踪，他这个角色，不能去替所有别的部门写他们本该自己写的材料，更不能把所有技术上的判断，都自己一个人全包下来，一种比较合理的分工是，由安全经理把规则给讲清楚，然后去监督各个团队，是不是真的按照这个规则去执行了。

　　4、研发和测试的团队负责的是技术的闭环

　　系统、硬件、软件，还有测试的团队，需要对自己所负责的那一部分安全工作产品，负起责任来，需求的分解、接口的定义、安全机制的设计、单元的测试、集成的测试，还有故障注入的测试，这些都不能只被丢给专门的安全人员去整理，应该是谁做的设计，就由谁来负责解释；谁做的测试，就由谁来负责提供那份证据。

　　5、质量的人员负责的是过程的符合性

　　质量的人员，主要去关注流程是不是真的被执行了、记录是不是完整的、版本是不是受控的、评审是不是最终形成了一个闭环，在做质量检查的时候，不应该只是去看文档的格式漂不漂亮，还要去看项目实际在执行的时候，跟文件里面所写的内容是不是保持一致的，一旦发现了过程上存在偏差，他们就要去推动纠正的措施，而不是仅仅在审核的表格里面打上一个勾就算完事了。

　　三、ISO 26262安全文化如何持续检查

　　ISO 26262的安全文化究竟能不能持续地运作下去，是需要靠一套检查的机制来维持的，在项目的早期，我们去看计划做得怎么样；到了中期，去看实际的执行情况；而到了后期，就要去看证据是不是完整，还有那些问题是不是都被关闭干净了。

　　1、定期去检查安全活动的完成情况

　　我们可以按照一个固定的周期，比如每个月，去检查一下安全计划里面的那些活动，当前都处于一个什么样的状态，去确认一下，哪些是已经完成的，哪些是延期了的，还有延期的原因又是什么，这种检查的内容，不需要搞得太虚，它最好能直接对应到具体的交付物和评审的记录上去。

　　2、去检查那些变更，是不是触发了新一轮的安全评估

　　不管是设计上的变更、供应商变了、软件的版本更新了，还是生产工艺调整了，都需要去判断一下，这些变动是不是有可能会影响到安全目标或者安全需求，在变更的记录里面，要写清楚对安全影响的结论，不能只是丢下“没有影响”这三个字就完事了。

　　3、去检查那些曾经被发现的问题，是不是真正地被关闭掉了

　　关于安全问题的关闭，不能只是听责任人在口头上说一句“已经处理好了”，我们还要去看到验证的结果、回归测试的情况、评审的记录，还有相关联的文档是不是都已经被同步更新了，在问题被关闭之后，相应的控制措施，也需要被同步地写入到设计、测试或者生产的文件里面去。

　　总结

　　总地来说，ISO 26262安全文化要怎么去落地，还有围绕安全文化的职责又要怎么去分工，这里面最关键的一点，就是要把安全的要求，拆解成项目里面能够去执行、能够去检查，还有能够去追溯的一个个具体的动作，管理层负责把资源和权限给到位，项目经理负责把活动排进整体的计划里面，安全经理负责提供方法并做好监督，研发和测试的团队去完成技术上的闭环，而质量的人员，则去检查整个过程的执行情况，只有当这些职责都被分清楚了以后，功能安全才不会仅仅停留在文件的层面上。