本期话题聚焦
- 开发功能安全产品项目的必要组织
- ISO26262标准在管理方面的具体要求
- 安全经理的任务，安全计划和安全证据
本期话题目录
1. ISO26262标准中管理相关部分概览
从上方视图可以看出功能安全管理涵盖整个安全生命周期，涉及从概念设计、产品开发、生产和运营、支持过程各个阶段的管理要求。
2. 功能安全管理的主要活动
从ISO26262标准的主体内容来看，功能安全管理部分主要涵盖以下活动：
- 创建、培养和维护安全文化；
- 建立组织特定的规则及流程(包括工具、模板、检查清单等)；
- 确保功能安全异常项应得到有效的传达；
- 经验教训库的建立和传递；
- 对相关人员进行功能安全培训；
- 决定执行安全生命周期的哪个阶段，分配安全活动和相关的职责；
3. 功能安全管理中的角色和职责
功能安全的项目管理中在管理上的两个重要角色：
- 项目经理；
- 安全经理；
标准中对于两者的职责及分工相关要求如下：
A project manager shall be appointed at the initiation of a product development concerning the item. (refer ISO26262_part2, 6.4.2.1)
The project manager shall be given the responsibility and the authority, in accordance with 5.4.2.7, to ensure that: (refer ISO26262_part2, 6.4.2.2)
a) the safety activities required to achieve functional safety are performed; and
b) compliance with ISO 26262 is achieved.
Jet Note: 从这条要求来看，确保功能安全在项目中落地并不是安全经理一个人该操心的事，项目经理才是整个项目的全权负责人，应提供功能安全达成所需的各方面项目资源。
The project manager shall verify that the organization has provided the required resources for the safety activities, in accordance with 5.4.2.5. (refer ISO26262_part2, 6.4.2.3)
The project manager shall ensure that the safety manager is appointed in accordance with 5.4.4. (refer ISO26262_part2, 6.4.2.4)
Jet Note: 安全经理是项目中的一个角色，对于功能安全的项目，项目经理需为项目任命一位安全经理来管理项目安全相关活动，如果项目经理本身具备相关能力，那项目经理本身可以兼任安全经理的角色，反之也是可以的。
以上要求总结来讲项目经理的职责有：
- 确保安全活动都被执行；
- 实现ISO26262标准的符合性要求；
- 安全经理被任命；
The safety manager shall be responsible for the planning and coordination of the safety activities in which the organization is involved, in accordance with 5.4.2.7. (refer ISO26262_part2, 6.4.6.1)
The safety manager shall be responsible for maintaining the safety plan, and for monitoring the progress of the safety activities against the safety plan. (refer ISO26262_part2, 6.4.6.2)
The responsibilities with regard to performing the safety activities shall be clearly assigned and communicated within the organization in accordance with 5.4.2.7 and 5.4.4. (refer ISO26262_part2, 6.4.6.3)
NOTE The safety manager is responsible for planning and coordinating the safety activities. Other persons can be responsible to detail the planning (see also 6.4.6.8) or to perform the safety activities (e.g. to plan or perform integration and verification activities and configuration management).
Jet Note：安全经理要负责制定安全计划(静态)，将安全相关的活动分配给组织对应的人员，并根据计划组织、协调资源来实施安全活动(动态)。任务分配过程中应对相关人员的能力进行识别，应确认对应人员具备实施相关安全活动的能力或者应对相关人员建立起这样的能力。
以上要求总结来讲安全经理的职责有：
- 计划并定期检查项目的功能安全活动；
- 创建和维护安全计划；
- 监督安全计划的进展；
- 组织建立功能安全相关的输出物；
- 对接客户及供应商的功能安全事项；
- 维护安全档案；
- 向项目经理汇报功能安全活动的状态；
Q: 你的组织配备了这样的安全经理了吗？
关于安全文化的要求及如何落地的解释参见《关于安全文化》上、下两篇文章的内容。
4. 关于安全计划
先看下标准中对于安全计划(safety plan)有哪些要求，以下为挑选的标准中关于安全计划的相关要求，详尽内容请参考标准对应章节。
The safety plan shall either be: (refer ISO26262_part2, 6.4.6.4)
a) referenced in the project plan, or
b) included in the project plan, such that the safety activities are distinguishable.
Q: 根据上述要求的描述安全计划和项目计划的区别与联系是什么？
The safety plan shall define the planning of the activities and procedures for achieving functional safety, including: (refer ISO26262_part2, 6.4.6.5)
a) the implementation of project-independent safety activities in accordance with Clause 5 into project-specific safety management;
The safety plan shall be updated incrementally, as a minimum at the beginning of each phase.
Q: 从这条要求的描述来看，安全相关的活动似乎还是跟常规的项目活动有些“独具特色”的地方，想想标准中哪些活动是功能安全所独有的？或者说哪些输出物是常规项目管理(如PMBOK)中没有定义但在ISO26262标准中是有要求的？
In the case of a distributed development, both the customer and the supplier shall define a safety plan regarding the respective safety activities. (refer ISO26262_part2, 6.4.6.10)
Jet Note: 不管是不是分布式开发，安全相关的项目都需要编写安全计划。安全计划用以计划管理和指导项目安全活动的执行，包括日期、里程碑、任务、可交付物、责任人及所需资源，实际实施安全管理过程中安全计划要从“静态”和“动态”两个维度来实施。安全活动包括安全生命周期内容的所有安全相关输出物及其验证与确认过程，如HARA、开发接口协议计划、验证活动计划、认可评审计划等。
Q: 那么安全计划需要包含哪些内容或者说安全计划要计划些什么？
安全计划详细的内容要求参考标准第2部分6.4.6.5章节的内容，概括性的来看安全计划需计划以下内容：
- 实现功能安全的活动和程序的规划
- 将独立于项目的安全活动纳入项目特定的安全管理
- 定制安全活动的定义
- 危险分析和风险评估的规划
- 开发活动的规划
- 开发接口协议（DIA）的规划
- 支持过程的规划
- 验证和确认活动的规划
- 确认审查的规划、功能安全审计的启动和功能安全评估的启动
- 每次发布的安全档案内容规划
- 规划相关故障和安全分析
- 提供相关项在使用中经过验证的论据
- 提供对软件工具使用的信心
安全计划的内容板块可参考下图示例。
4.1 安全计划中关于组织架构的角色和责任举例
安全计划中应将不同安全活动分配的对应的角色并定义其责任，表达方式不限，可以以图表方式也可以用表格方式，只要活动与人员及其责任能一一对应即可，例如下方图中的表表示方式和表格表示方式。
图表表示方式：
表格表示方式：
4.2 关于开发接口协议(DIA)
- 目标：为相关项及其要素描述分布式开发的过程及对应分配的责任。
- 适用于每一层级的客户-供应商关系。
- 也可适用于内部供应商。
- 只有合格的供应商才能开发安全相关的系统及组件。
- 签订协议前客户需对供应商进行评估和审核。
Jet Note: 签订DIA其实对供应商在功能安全这块的开发能力起到了间接评估的作用，DIA中定义了功能安全标准全生命周期过程输出物的要求，如果供应商不具备这个能力那DIA一时半会签不下来，所以功能安全的项目对供应商还是有基本的要求，至少组织架构上得有负责功能安全的这么个岗位，不然很难和客户的功能安全团队对接顺畅。
由于DIA往往是客户给的供应商进行确认的一份输出物，所以格式往往客户会定义，但这不是绝对的，最终的签订是需要双方都确认，格式在双方确认过程中可以进行改动，只要双方认可即可。
标准第8部分附录B例举了DIA的示例，参见下方。当前比较流行的方式是采用RASIC的格式来定义DIA，参见《ISO26262功能安全概述(三)》（ISO 26262 功能安全概述(三)-CSDN博客）一文中关于DIA的介绍。
4.3 安全异常管理
只要是项目管理就会有异常管理，安全管理也不例外，安全异常自然也要在日常安全管理中进行监控。
Q: 道理是这么个道理，但什么样异常算安全异常？安全异常什么识别？由谁来识别？
其实这些问题在日常项目管理中也会遇到，只不过是ISO26262标准将这些问题聚焦到了安全这个属性上并按照一定的流程提出来了。日常项目管理中的风险项、开口项都属于异常，这些异常既有流程层面的也有技术层面的，对于安全的异常需要的是识别当前的开口项问题是否会影响到产品的安全性，这个识别工作可由问题提出者去执行，也可以是功能安全工程师去识别，只要具备对应分析能力即可，但需要明确定义相关责任人。
标准要求组织需定义一个明确的流程来说明组织是如何处理安全异常问题的，问题的处理最终要形成闭环，这么看来安全异常管理其实就是问题管理，只不过有些“高冷”的说我关注的只是安全的问题。下图安全异常管理流程示例供参考。
然而现实情况是对于安全相关的系统技术层面的问题80%以上是安全相关的，所以功能安全管理要融入到日常项目管理中，直面问题才能做好安全异常管理。
4.4 能力管理
标准对于组织的能力管理提了条说不出任何毛病的要求。关于能力管理标准要求如下：
The organization shall ensure that the persons involved in the execution of the safety lifecycle have a sufficient level of skills, competence and qualification corresponding to their responsibilities. (refer ISO26262_part2, 5.4.4.1)
这条要求提的可谓“天经地义”啊。进行一款产品的开发，人力资源是第一位的，活得有人干才有成事的可能，但事情干得好不好对应负责人的业务能力是主要因素，所以在创建WBS的过程中需要考量对应责任人的能力是否能胜任所分配的任务，如果不能，在条件允许的情况下选用能胜任的人，或者对相关人员进行能力建设，如标准提到的培训就是能力管理要用到的手段，培训可以是内部的也可以是外部的。
不管怎样，总之得确认功能安全活动的干系人具备实施对应活动的技能、能力及资质。从实践经验来看，实施内部功能安全培训是最经济高效的方式。
5. 关于安全档案(Safety Case)
Q: 什么是安全档案(Safety Case)? 安全档案(Safety Case)这份输出用于做什么？
在回答这个问题前我们先看下标准对应安全档案(Safety Case)的定义。
safety case 安全档案：argument that functional safety (3.67) is achieved for items (3.84), or elements (3.41), and satisfied by evidence compiled from work products (3.185) of activities during development. (refer ISO26262_part1, 3.136)
Jet Note: 安全档案将作为项目功能安全符合性/满足性的证据文件，用于提供清晰的、全面的及强有力的论据证明系统运行在特定环境下不存在不合理的风险。在前面的文章中提到过功能安全是一门“流程和技术的结合体”的通用学科，安全档案中的论据也将从流程和技术两个维度来证明相关项满足标准的安全要求，如下：
- 产品论据：如，安全机制。
- 流程论据：如，方法指引、审查、认可评审。
Q: 关于安全档案标准有哪些要求？
先看看下方标准的内容。
A safety case shall be developed, in accordance with the safety plan, in order to provide the argument for the achievement of functional safety. (refer ISO26262_part2, 6.4.8.1)
The safety case should progressively compile the work products that are generated during the safety lifecycle to support the safety argument. (refer ISO26262_part2, 6.4.8.2)
标准关于安全档案的要求总结来看有以下几点：
- 应根据安全计划进行制定。
- 应逐步根据安全生命周期过程中生成的工作成果(work product)进行编辑。
- 独立执行认可评审(通常有另一个部门进行评审)。(这点隐含在认可措施的表格中，见下图)
Q: 根据标准的要求及内容提示，安全档案需要包含哪些信息才算完整呢？或者说安全档案的编写要体现哪些论据内容呢？
从上述内容可知安全档案需要收集产品/技术和流程两个维度的论证，其内容可以从两个维度考虑并结合安全计划中规划活动进行创建。下方列出来部分安全档案的内容板块，供参考。
- 认可报告；
- 需求规范；
- 安全分析报告；
- 安全计划、组织结构图、安全规则；
- HARA 报告；
- 开发接口协议；
- 测试计划及评审报告；
- 测试报告及评审报告；
- 评估和审查报告；
- 变更需求、释放备注信息；
Jet Note: 项目实践过程中要详尽地写好一份安全档案并非易事，安全档案的编写是一项持续性的工作，伴随着开发、验证阶段的各项活动。组织在流程上需要提供良好的配置管理系统或方法以便安全档案更好、更准确的收集当前阶段的活动状态证据，这些证据的需要各个板块基于支持，比如系统、测试团队、质量等。输出物版本基本不动或频繁变动、人员变动、多变种项目、工具系统变更等等这些都会影响过程证据的收集。
下期预告：ISO26262的功能安全管理（二）
- 认可措施；
- 验证；
- 生产、运行、维修和报废的功能安全管理；
参考：
[1] ISO 26262-2:2018, Management of functional safety
更多精彩内容欢迎关注微信公众号：功能安全落地漫谈
扫一扫
2103
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
