根据前一篇（《关于安全文化（上）》关于安全文化（上）-CSDN博客）关于安全文化的介绍，了解到安全文化其实是一种流程规范的抽象，嵌入在公司产品开发流程的各个细节中，拥有好的安全文化可以说意味着功能安全落地有了流程上的支撑和保障，让功能安全活动的展开不再有那么多的“开头难”问题，这是件令人兴奋的事。

Q: 那么标准中对于安全文化具体有哪些要求呢？

作为安全管理的一部分，标准要求组织要建立起一套自己的功能安全开发流程，用于指导并保障功能安全的活动都是朝着实现项目功能安全的目标前进。具体的要求如下。

> The organization shall create, foster, and sustain a safety culture that supports and encourages the effective achievement of functional safety. (Part 2_5.4.2.1)

Jet Note: 此要求在具体实施层面更多的是要求：

1）将功能安全的流程融入到组织的开发流程中，基本的如在原来没有考虑功能安全输出物的项目计划中将各阶段安全相关的输出物同步定义清楚；

2）需要保证参与安全活动的人员接受到功能安全相关的培训，且培训需要有一定计划性、针对性、持续性，让团队成员对功能安全的必要性有充分的认识。说直白点就是要通过持续性的培训让团队成员认识到功能安全是什么，为什么要，该怎么做，让团队成员形成一种安全开发意识。

> The organization shall institute, execute and maintain organization-specific rules and processes to achieve and maintain functional safety and to comply with the requirements of the ISO 26262 series of standards. (Part 2_5.4.2.2)

Jet Note: 此要求需要组织输出一份公司级的关于功能安全开发的流程规范文件，该文件需定义清楚公司实施功能安全活动的流程和各环节的的职责。其实标准定义的V模型本身就是一个通用的流程定义，只不过需求基于此进行展开和根据组织自身情况进行细化。

具体的可参考下图的定义方式。

图1：V 模型

由V模型导出的功能安全开发阶段的流程定义参考下图。

图2：功能安全开发流程定义

由V模型导出的概念阶段的流程定义如下(供参考)

图3： 概念阶段开发流程

> The organization shall institute and maintain effective communication channels between functional safety, cybersecurity, and other disciplines that are related to the achievement of functional safety. (Part 2_5.4.2.3)

Jet Note: 此要求可以在上一条(Part 2_5.4.2.2)定义组织的功能安全开发流程规范时进行同步覆盖，即在定义功能安全开发流程的同时同步考虑其他与之相关标准的要求，典型的如ISO21434之网络安全，具体实施层面可以是在定义功能安全的开发流程时将对应节点的网络安全相关输出物进行同步考虑，比如安全计划里同步定义好功能安全网络安全的输出要求，需求定义阶段同步考虑功能安全和网络安全的需求等。

> During the execution of the safety lifecycle, the organization shall perform the required safety activities, including the creation and management of the associated documentation in accordance with ISO 26262-8:2018, Clause 10.（Part 2_5.4.2.4）

Jet Note: 这是一条文档化管理的要求，即组织在项目的整个安全生命周期要按已定义好的开发流程规范进行各阶段输出物的有效管理，这包括输出物的编码及命名、创建、存放、权限管理等。具体怎么进行文档管理可以根据公司现有资源进行安排，如用服务器或专门的文档管理工具，或是公司现有的其他系统，只要能做到上述要求即可。

> The organization shall provide the resources required for the achievement of functional safety.（Part 2_5.4.2.5）

Jet Note: 这是基本要求，非功能安全项目也需要相关资源来开展项目，只不过这里的资源除了基本的人力、工具外，还包括流程方面的各种数据库(e.g. 测试用例库、经验教训库etc.)、开发指引类文件、各类checklist等, 强调的是一种全方位的支撑项目开发的资源，但往往这些“软性”的东西是大部分组织所缺乏的。

> The organization shall institute, execute and maintain a continuous improvement process, based on:

— learning from the experiences gained during the execution of the safety lifecycle of other items, including field experience; and

— derived improvements for application on subsequent items.（Part 2_5.4.2.6）

Jet Note: 此要求可以在(Part 2_5.4.2.2)定义组织的功能安全开发流程规范中进行同步定义，即在该流程规范中定义组织是如何进行持续改进的。其实持续改进并非功能安全的新概念，质量里的PDCA环就是一种持续改进的方法论，可根据PDCA的方法论定义组织的持续改进策略。

图4：PDCA环

这里我想分享一个关于功能安全开发实现持续改进落地的简化实用步骤，参考如下简化流程图。

1）将项目管理的开口项问题进行清单化管理；

2）将开口项进行闭环追踪，明确责任人和问题解决方案及日期；

3）将方案文档化形成经验教训案例，并根据文档化管理要求实施案例文档的编号管理；

4）从经验教训文档中总结出对应的产品开发需求并进行编号；

5）将总结出的需求反馈到相关项目的需求规范中并同步更新对应需求规范；

6）通知开发团队相关需求更新，实施对应需求的实现及验证。

图5：经验教训闭环流程(简化的)

> The organization shall ensure that the persons responsible for achieving or maintaining functional safety, or for performing or supporting the safety activities, are given sufficient authority to fulfil their responsibilities.（Part 2_5.4.2.7）

Jet Note: 此要求可以在(Part 2_5.4.2.2)定义组织的功能安全开发流程规范中进行同步定义，比如该规范会声明产品开发过程中安全这一属性的优先级最高，应确保安全想过的问题都得到妥善的解决。该要求还涉及配置管理的权限管理，典型的如功能安全经理需具备访问标准要求的所有输出物的权限来开展功能安全的开发、管理活动，同时得定义好各功能小组对应安全活动责任人及其权限，其权限要和职责匹配。

以上就是标准关于安全文化的具体要求，总结来讲这些要求都可以集中在一份输出物上进行满足，即标准要求的 ‘Organization-specific rules and processes for functional safety’ 这份输出物。

该输出物也就是上文提到的组织的功能安全开发流程规范，把这份流程规范按上述要求及提示定义好，是组织安全文化落地的第一步，接下来就是执行的事。个人认为优秀的安全文化落地的终极表现是组织从“别人要你这样做到我自己要这样做”的转变。

参考：

[1] ISO 26262-2:2018, Management of functional safety

更多精彩内容欢迎关注微信公众号：功能安全落地漫谈