MUNIK解读ISO26262--验证活动之认可措施_iso26262v模型

接受过功能安全培训或者经历过功能安全项目开发的朋友应该对V模型的概念比较熟悉，ISO26262标准对于设计过程中的验证活动比较关注，所以一般产品的开发过程都会遵循V模型，也就是基本上所有的工作成果，特别是设计环节的活动都要有对应的验证活动。

在上图中我们就可以明显的看到在part4,part5以及part6阶段都有对应的V模型。

这次我们主要讲一下在ISO 26262中比较特殊的一种验证活动，“认可措施Confirmation measures”，它包含以下三个方面：

1. 认可评审（Confirmation review）
2. 功能安全审核（Functional safety audit）
3.  功能安全评估（Functional safety assessment）

注：虽然这三个活动的名称意思比较相近，但是在ISO 26262中是有特指意义的，所以在实际执行的时候是要区分清楚，并且在一些文档的描述上要注意用词的准确性。

为什么会讲认可措施活动是一个比较特殊的验证活动，主要的原因在于这三个活动的实施是有独立性要求的，并且独立性等级与所开发产品的ASIL 等级关系密切。标准对于独立性的划分如下：

1. ——:对于认可措施无要求和建议（想做就做不想做可以不做）;
2. I0:宜执行认可措施;但如果执行,应由与负责创建工作成果的人员不同的人员执行（最好做，不做也可以，做的时候，执行认可措施活动的人（监考老师）和创建认可措施验证对象的人（考生）不能是同一个人）;
3. I1:认可措施应由与负责创建工作成果的人员不同的人员执行（要执行认可措施，监考老师和考生不是同一个人就可以）;
4. I2:认可措施应由独立于负责创建工作成果的团队的人员执行,即由不向同一个直接上级报告的人员执行（要执行认可措施，监考老师和考生的直接上级不能是同一人，例如硬件安全分析的认可措施可以由软件团队或者测试团队的人来执行）;
5. I3:认可措施应由在管理、资源和发布权限方面与负责创建对应工作产品的部门独立的人员执行（要执行认可措施，而且是独立性最高，在管理和资源上就要独立，比如位于不同的成本中心，一般比较大型的开发组织或机构会有专门做认可措施的部门和团队，当不具备此条件，通常可以由第三方机构来实施）。

1. 认可评审（Confirmation review）

认可评审活动我们一般缩写为CR，如果将功能安全产品开发看作是一条直线，那么CR活动只是对直线上面的几个关键点进行验证，判断其开发过程以及结果是否满足标准，这几个关键点其实对应的就是重要的几个安全活动，标准对这里的几个重要活动是有明确定义的，具体如下图。

这里面需要重点强调两个内容：

1. 影响分析的CR：标准仅要求对于相关项层面的影响分析需要执行CR活动，而在要素复用层面是不需要执行CR。
2. 集成和测试策略的CR：标准要求的是对于4-7的活动执行CR，也就是系统层面的集成（软硬件之间的集成，子系统集成到系统，系统集成到整车），而在part5，part6中的硬件集成，软件集成，是不需要做CR活动的。

1. 功能安全审核（Functional safety audit）

Audit则针对的是整个产品开发周期，关注的重点是产品的整个开发过程有没有遵循ISO 26262的标准要求以及公司搭建的流程体系要求，比如标准要求开发ASILB的产品必须做归纳分析，通常是FMEA，那么在Audit过程中就是要看有没有按照标准和流程的要求执行归纳分析（至于归纳分析是否正确，合理，完整，则是下一个阶段评估（Assessment）考虑的事情）。

下图就是标准对于Audit独立性的要求。

1. 功能安全评估（Functional safety assessment）

Assessment也针对的是整个产品开发阶段（所有的工作成果），并且要求在研发工作开始时就要开始执行，也就是要跟随项目进度一步步执行，只要配置管理发布出来一份工作成果（WP），那我们就要对其的正确性进行评估。它关注的内容就比较全面和细致，不仅关注产品的开发流程是否符合标准（这里其实也就是Audit的内容，所以标准有提到Audit的内容是可以纳入到Assessment中的），还要关注所有工作成果的合理性，完整性（因为是所有的工作成果，当然也包含CR中的工作成果，所以CR的结果也可以是Assessment的一部分）。

比如在架构设计过程使用了ASIL分解，至于分解的合理性，由于没在CR范围内，并且不是Audit关注的内容，所以对其的验证就要依赖内部的评审和Assessment。包括设计过程中考虑的一些安全机制，它的覆盖率以及安全机制设计的合理性，也要在Assessment阶段进行再次关注。

CR,Audit,Assessment三者之间的相同点和不同点：

1. 时间节点：三者都要求在生产发布前结束；
2. 辅助人员：CR与Assessment在执行期间，验证对象团队可以指定一名辅助人员协助评审员或评估员开展工作（这时候评审员或者评估员很有可能是公司外部人员，比如第三方机构的审核专家），因为辅助人员对团队内部活动比较熟悉，评审员或评估员所需的资料或证据其可以比较高效准确的进行提供，但是其独立性最低要达到I1；
3. CR，Audit，Assessment这三个活动并非完全独立，相互之间是可以互相参考和借鉴的；
4. 从上面的独立性表格中，我们可以看到，ASIL B的功能安全产品，并不强制要求执行Audit和Assessment，但如果执行这两个活动，则独立性最低要达到I1(见I0的定义)。

对于认可措施在项目中实施是应该关注的重点，标准part2附录D已经给出了一些详细的参考，所以在自行实施认可措施活动时，可以借鉴此处的内容。