功能安全——安全计划

1.什么是安全计划

安全计划，其实本质上就是给功能安全的活动和输出产物定义一个开发时间，但是因为功能安全开发本身是依赖于项目的，所以安全计划应该隶属于项目计划，它是项目计划的一部分。所以只需要做好三件事，第一定义输出物和活动，第二定义交付的最终版本要求，第三定义每个时间点的交付状态。举个 子，

1.项目交付物：软件单元测试报告

2.最终版本内容要求：因为是ASILD的项目，要求做MC/DC，覆盖率100%

3.项目分为两次交付：第一个版本：MCDC覆盖率做到80%，第二个版本：MCDC覆盖率做到100% 或者第一个

版本：不交付MCDC报告，只做函数覆盖率和分支覆盖率100%，第二个版本：MCDC覆盖率做到100%

2.为什么要做安全计划

在DIA中提到了很多交付物，上面也提到，项目交付过程中，会有多个版本，如果一次性做完的话，从技术的角度来看，当然最好，可以保证每个交付版本的产品都更安全；但是从项目管理的角度来看，这样未免功能安全的代价过高，在一些基础版本，OEM并不会进行路试，只是做基本的HIL测试或者台架测试，从功能安全的角度来看，除了一些紧急的自我保护和，并不会造成过大的风险，所以也确实没有一次性做完的必要，况且客户的需求像是夏天的天气一样，说变就变，牵一发而动全身，有的功能还没开发完，即使完成的功能做了也要再改，长此以往，大家都总结出来，功能安全输出物要做，但是可以分阶段做，只要在量产前将所有的输出物的状态做到100%就可以了。

3.安全计划需要谁来做？

一般安全计划是由功能安全经理或者功能安全项目经理完成，安全计划需要和项目计划保持一致，所以需要和项目经理做好同步，同时也需要和各个部门的经理做好同步，确认所有的时间点是否能够交付定义状态，这样才能保证计划是有意义的。

4.安全计划在什么阶段做？

在DIA中提到，其实在DIA结束之后，确定了交付物之后，就可以安排计划了，计划吗，肯定是先安排计划，然后再做事，当然我承认国内做的计划一般都没有国外做的好，因为国内太卷了，有些公司安排的计划和实际做事没啥直接关系，就只是为了做计划而做，有些小公司甚至觉得安排计划没有意义，反正也不会按照这个去执行，做计划还浪费时间，不如直接开干，我都经历过，我对计划的理解在于如果对于项目开发很熟悉，可以评估出大致准确的时间，是可以在项目中规避一些风险，也有利于项目组和各个部门井然有序的安排工作任务，可以预防资源短缺，技术储备不足，人手短缺等问题造成的不必要的风险，在项目初始阶段就可以识别出来，防止项目开发过程中的措手不及。

5.安全计划应该怎么做？

1.定义安全计划的范围

只能代表安全的输出物和活动的计划范围。——明确安全计划的范围

2.定义项目的范围

2.1技术范围——明确功能安全输出物和活动

2.1.1简单描述产品的功能，工作环境，整车架构图之类的描述，从整车和系统的角度去分析功能安全需要考虑的范围。——明确产品功能和功能安全范围

2.1.2描述整车层面相关项定义，危害分析以及风险评估，安全目标，功能安全概念——明确功能安全输入

2.1.3软件和硬件是否有复用模块，技术上关于复用模块的安全分析，在用证明等等（如果平台功能复用的话，有些流程工作是可以裁剪的）——明确功能安全裁剪范围

2.2时间范围——明确时间

2.2.1发布等级定义——明确交付状态

RL1——发布产品只能用于台架测试，整车静态测试，整车低速行驶，驾驶员负有全部责任，功能安全没有实施或部分实施，没有功能安全相关文档也没有其他文档覆盖ISO26262。（也就是说不建议路试，如果非要路试，那出问题了自己负责）

RL2——发布产品只能用于封闭道路，授权驾驶员进行整车原型测试，车辆不能交付给终端客户，功能安全只部分实施，驾驶员能够有特殊的安全机制或方法控制车辆，功能安全文档结构被定义，但是只有最重要的模块文档符合ISO26262（例如紧急关断）

RL3——发布产品可以用于开放道路，授权驾驶员进行整车圆形测试，车辆不能交付给终端客户，功能安全根据客户需求全部实施，产品没有已知的高功能安全风险，功能安全技术评估报告不完全交付，功能安全文档包含所有重要的方面，ISO26262部分实施。

RL4——发布产品可以用于开放道路正常行驶，车辆可以交付给终端客户。根据客户需求功能安全已经完全实施和验证，功能安全技术评估释放，只能运行允许存在较小的差异，功能安全相关模块符合ISO2626，功能安全文档释放，并且完全符合ISO26262。

2.2.2项目时间计划——列出具体交付物，给出具体时间（各个环节的交付物在DIA中已经明确，功能安全——DIA - 穷困潦倒的资本家的文章 - 知乎 功能安全——DIA - 知乎）

整体目标

功能安全

系统

系统测试

硬件

软件

其他

3.项目功能安全组织架构

3.1功能安全经理职责定义

3.2功能安全专家职责定义

3.3相关责任人——明确负责人，出问题后可以快速找到相关人员，各个环节的输出物也需要相关负责人提供

流程工具负责人

功能安全负责人

系统负责人

测试负责人

软件负责人

硬件负责人

3.4支持过程——公司是怎么管理的，就怎么写，主要包括以下几个方面

文档和配置管理

变更和问题管理

模块认证

SOP后功能安全管理

4.裁剪的功能安全活动和方法

这里主要定义功能安全管理，系统，软件，测试，应该交付哪些文档，实施哪些安全机制以及原因是什么，功能安全交付物在DIA中已经定义，也可以根据实际情况自行调整。

5.验证策略

验证策略主要包括三部分

认可检查（Confirmation Reivew）

功能安全审查（Functional Safety Audit）

功能安全评估（Functional Safety Assessment）

下表中的“相关项”就是指你们正在做的产品

以上三种检查其实在safety plan中的定义很简单，

1.公司可以支持做哪些检查（理论上功能安全要求三种都要支持）

2.什么时间可以做这三个验证和检查，也就是检查计划和状态

3.从DIA中提取出来检查内容，来定义一些更细节的检查项,检查方式以及检查具体时间等等

当然标准里还有验证措施独立性的要求，公司自己定义的review的细节必须符合功能安全要求。

总共有四个级别

I0：作者和review人员可以是同一个人，也可以是不同的人，(没有强制要求)

I1：作者和review人员必须是不同的人员，(一般同组的同事就可以review)

I2：作者和review人员必须来自于不同的团队，(不是同一个直属领导/经理)

I3：作者和review人员必须来自于不同的部门/公司，(不同的总监或者老板)

总结一下，功能安全计划的大致工作内容：

计划和协调组织安全活动

安全计划的维护和监督执行情况

安全活动的责任人员分配

安全计划与项目计划同步

活动计划，流程计划，功能安全审核，功能安全评估

裁剪的证据

安全计划的更新

分布式开发，客户和供应商都要有计划

还有目标、活动之间的相关性，需要的资源，时间节点，产出物的定义等等

以上的输出物或者活动都需要在功能安全计划中定义好，当然计划相关的这些都是宏观项目层面，关于输出物和活动的内部细节会在后续的文章逐一解析描述。