内容提要：本文我们来介绍一下，推进任务分配好以后的准备工作如何做。

之前我们介绍了功能安全实施前应该了解的一些事项，包括风险、标准的对象范围以及推进工作的任务分配。这次我们来介绍一下，推进任务分配好以后的准备工作如何做。

建立推进组织

推进工作布置好以后，负责人就要开始一步一步推动内部工作的开展。这个阶段，有几件事情希望管理层能够注意。

主持人权利授予

首先，明确主持人的职位、权限，并通知到公司的内部。ISO26262的Part2(功能安全的管理)中提到了“5.4.2安全文化”，其中有一条提到组织应当对开展或支持安全工作的人员给予足够的权利。

上次我们也提到了，ISO26262是涉及到产品开发全生命周期的庞大的标准体系。因此，负责安全工作开展的人，需要和大多数的组织、部门、人员交流协调。主持人如果内部的职位和权限不明确，各个部门之间的协调会非常困难，恐怕不能产生有效的应对策略。严重的情况下，会与开发团队发生冲突、引起意见分歧，最终结果变成了脱离实际情况的形象化工程。　

一般主持人要理解标准，将要求的内容落实到公司内部流程上，是以技术为核心的活动。但是实际上，多数时间和精力都花在部门之间的协调、部门要求的收集这样的协调工作上。　

为了减低少这项工作的负担，不仅主持人的权限需要明确，而且也有必要明确一位支持他工作的管理层作为后盾。

同时，各个关联部门的接口人、决策人是谁也要明确。这些都能防止主持人被孤立，让功能安全工作得到有效、顺畅的开展。一定要清楚，主持人的积极性能否调动起来，关乎安全工作成败。

推进资源保障

其次，必要的资源，特别是对推进组织的人力资源分配。即使分配了权限，如果不给予推进的资源，那么也是没有意义的。关于这一点，ISO26262中的Part2也提到了，必须提供完成功能安全工作需要的资源。

这里提到的资源，不仅是人力资源，还包括开发支持工具等。话说回来，实际上最困难的应该就是人力资源的保障。国内的企业通常认为功能安全是迫于外来的压力才做的额外工作，而不是公司的核心业务。所以，如果不当做核心业务，那么人力资源保障就会变得困难。但是功能安全对于安全相关的产品来讲，并不是额外工作，而是产品开发流程。当然，增加了一些“确认措施”等以前没有听过的工作，但是这些都是从其他领域获得先验知识，应该作为制造安全产品的技巧来掌握。去掉“额外工作”的偏见是基本的前提。

推进组织成立后，在功能安全实施之前，工作量最大的就是流程的搭建了。这个工作借助外部资源的案例比较多。对标准理解比较深的专家来做的话可能效率更高。但是，如果完全交出去做，那么搭建的流程可能会脱离实际，即使有了满足标准的漂亮的流程，日常开发人员用的也不好。

为了避免这样的结果发生，在灵活使用外部资源的时候，对目标和现实(公司内部情况)理解深刻的有经验的人必须要参与进来。　

指导方针和计划

推进组织建立好以后，最开始的工作是制定活动的指导方针，战略和计划。不夸张的说，活动的计划是实现近期目标和战略的决定因素。下面我们介绍下，制定计划的时候至少需要明确的几个问题。

1）确定基础流程

基础流程是追加功能安全活的基础。多数情况下是基于企业已经导入的质量管理流程(ISO9001，TS16949等)。一方面参与过质量和可靠性相关工作的人对流程比较熟悉，另一方面功能安全活动的前提也是“质量管理系统”，所以比较适合作为基础流程。但是，因为这个标准是面向组织的管理标准，ISO26262的Part2(功能安全管理)，Part8（支持流程）等和质量管理流程相似度较高，而Part4(系统)，Part5(硬件)，Part6(软件)等工程相关的流程需要有另外的应对方案。

另外，重视软件开发的企业经常使用CMU/SEI的CMMI(CapabilityMaturity Model Integration)、而欧洲的汽车企业采用Automotive SPICE的也比较多，所以也有很多案例是基于这些流程的。在欧洲，一直以来对软件比较热衷的博世以CMMI为基础流程，比较热衷与推广Automotive SPICE的大陆等则以Automotive SPICE为基础。所以流程搭建的战略定位也是基于之前的的资源、经验方面的优势。

特别是Automotive SPICE在欧洲用的比较广发，和ISO26262重叠部分较多。可能是最适合功能安全实施的基础流程。从这一点入手，基于AutomotiveSPICE扩展功能安全(典型案例是瑞典的SS7740)的话，也可以灵活运用，规划一个综合版的SPICE活动。

表1　ISO 26262和Automotive SPICE的关系

2）功能安全活动的任务分配

ISO26262中有一个负责产品功能安全开发的责任人，叫做安全管理员。工作内容类似项目管理。项目管理也可以担任安全管理工作。但是，因为项目管理有成本削减和交付期限的压力，而安全管理是将安全放在最高优先级的，两者兼任的利弊应该慎重考虑。

安全管理员的法律责任

每年欧洲VDA QMC会组织召开VDAAutomotive SYS Conference。会议中也会请律师过来举行workshop，从法律角度去探讨安全管理员的责任。因为是根据过去的一些判定去做判断，很难界定安全管理员的责任界限，但是无论怎想，一旦产品发生安全问题，提交到法院去处理的话，安全管理员是一定要被卷入其中的。

功能安全活动除了安全管理员之外，还设置实施评审的评审员，以及执行检查的检查员，实施功能安全评估的评估员等。另外还需要有在产品各个开发阶段负责验证措施的专家。

安全管理员工作的角色除了安全方面的责任之外，还有项目管理类似的责任。

另外，确认检查、功能安全监督、功能安全评审等新的角色，需要具备什么样的经验，什么样的能力，以及今后应该具备什么样的技术，也是困扰很多公司的课题。这一点，应该结合后面讲述的组织建设课题，在充分的理解标准要求的基础上慎重的考虑。

表2　验证措施概述

3）功能安全的组织架构(确保独立性)

这里的验证措施根据开发产品的安全等级(ASIL: Automotive SafetyIntegrity Level)以及针对的对象不同，可以独立变化。对于要求安全等级最高的ASIL D的产品，通常要求由开发验证措施的团队之外的组织执行。总之，对于功能安全的权责，不仅要考虑执行的人需要具备什么样的能力，还有必要考虑要如何保证这些活动的独立性，需要什么样的组织，以及什么样的指挥系统等组织论层面的切入点。

验证措施的目标可以总结为以下两点：

通过客观的视角以及不同切入点(结果方面的切入点或流程方面的切入点)的检查，发现开发者遗漏的点。

即使发现安全上的问题，在业务上(成本和交付日期)也不会受到很大的压力，能够得到有效的解决。

什么样的人负责功能安全活动工作、组建什么样的组织、该组织应该承担什么样的责任，这些课题要根据各个公司的具体情况来制定。但是，无论什么样的应对措施，都必须符合此标准活动的目标。否则，只在形式上满足标准要求的话，活动本身没有任何效果，只是在为了满足标准而制作标准。

例如，如果验证措施仅仅是形式上的检查，那么安全上的疏漏大部分是找不到的。无论对于实施的一方还是被实施的一方都是不好的。

重要的是，在产品开发过程中，通过核查监督捕捉安全上的漏网之鱼。通过将这些应对措施以具有组织特征或优势的形式开展，最终成为获得实质性成果的捷径。

关于验证措施的补充

在航天领域，有独立于资本方组织实施的IV&V（IndependentVerification＆Validation）活动。是在国际空间站开发的时候，NASA提出的方案，JAXA吸收并采用。这项活动，就是由独立的组织从客观的角度对产品进行评价，并根据需要充分的利用先进技术。现在IV&V活动，已经在载人航天领域多个航天器开发中得到应用。在考虑验证措施方面，有重视产品偏差知识和经验的公司。也有像航天领域的例子一样，重视客观的评价知识的。当然，没有对和错之分，根据公司的情况和指导方针来考虑就好了。

GAP分析

GAP分析，是分析已有的流程在多大程度上满足ISO26262的要求，还有哪些没有满足，找出流程之间的差距的工作。本文中，都是在计划制定后直接实施功能安全流程，多数情况下事前就知道公司并没有功能安全相关的流程，所以很多案例中没有做GAP分析。后面，一边定义流程，一边逐步的确认方向性以及和每个标准的相容性。采用一边向前跑一边回头看的方式的越来越多。

另外，最近已经有开始带着功能安全任务进行产品开发的案例，检验开发的成果(技术安全要求以及系统设计文档等)是否满足标准的“确认审查”工作越来越多。

流程搭建工作和实际的产品开发项目如何融合起来，依赖于公司的战略和计划，有计划的做一些GAP分析和兼容性评估是个好办法。关于兼容性评估在后面“流程实现”的地方会再阐述一下。

作者：牛喀网特邀专家
牛喀网文章，未经授权不得转载！