内容提要：本文介绍ISO 26262导入时最初的难关：流程搭建。

本连载以中小供应商为对象，主要介绍ISO26262的実践经验。第3回我们介绍下ISO 26262导入时最初的难关：流程搭建。当中会提到“裁剪”和“DIA(开发接口协定)”等在ISO 26262频繁使用的用语。 前面一篇对功能安全导入的准备工作进行了重点解说。本次虽然说也算是准备工作的一环，不过，作为功能安全导入的最初的难关，是想试着说明一下功能安全流程的搭建。

本公司的责任范围

下图显示了ISO26262设想的典型车载系统构成要素。

图1 典型车载系统的构成

本公司负责的功能安全流程的范围，虽然看上去是一目了然的事情，但是跟公司开发的产品在车载系统中处于怎样的位置有很大的依赖关系。汽车主机厂需要覆盖ISO26262所有Part的流程。大的供应商与汽车厂商几乎需要同样的流程，也会涉及到系统开发(PART 4)以后的流程。

对于本连载的对象-中小供应商，只负责图1中子系统A和B，系统B 1和B2，或只负责硬件(HW)和软件(SW)的情况很多。在这种情况下所需要的流程，可能系统开发(PART 4)以后，以 HW开发(PART5)和SW开发(PART 6)为中心的流程就可以应对。当然，产品开发管理和支持相关的Part2，Part8、Part9的流程也是需要的。

在功能安流程的搭建上，本公司产品的负责范围和ISO 26262要求的哪个PART对应需要事先明确。

特别是中小供应商的情况下，必须在人力和预算有限的条件下高效的应对，好好地瞄准目标是非常重要的。首先，想好各种各样的产品和开发模式，制定对所有的情况都能应对的流程从中长期战略上看是很有意义的。但是，如果想着重先用最低限度的劳力尽快实现功能安全的话，首先以可以想到的产品和开发模式为焦点，在这个基础下搭建对应的流程是相对更现实的。

实际的产品开发中，并不是像表中那样粗略的分配固定的任务，而是根据产品以及部件等级进行具体分配。这种情况下，与其从ISO26262各章定义的范围眺望自己公司的小范围相比，以实际的合同案件或者业绩为基准，可以搭建比较符合现实的流程。

合同中不可或缺的流程要素一

ISO 26262的PART 8的5节“分散开发接口”讲到，产品开发之前，汽车制造商和供应商，或供应商之间的协议中规定各种各样的要求事项。这其中不仅仅要有必要的功能规范这样的技术信息，还包含责任范围，流程和裁剪等管理性的要素。也就是说，今后功能安全相关产品的合同，至少在这里明确分配的责任范围要接入本公司的功能安全流程。

流程的裁剪

裁剪是允许在规定流程的一定范围内按照顺序做替换、整合或省略的考虑，但是这并不意味着可以无限制的自定义流程。裁剪的时候，必须要说明其正当性。不能简单的认为可以省略或者变更作业内容。这里所说的裁剪内容，指的是裁剪之后的开发流程。不做裁剪的话，原本的功能安全开发流程就是裁剪内容。如果有作业的合并，省略，以及支持工具替代的话，其结果(流程)就是裁剪内容。一般是在开发计划和安全计划中体现裁剪内容。

基于部件认定的再利用

基本上是按照以上的想法缩小责任范围，根据相关标准文件的要求定义可满足功能安全的流程。在此基础上，也会有一些例外的处理，这里也想稍微提一下。

通常，开发功能安全相关产品的时候，必须在满足标准中相应Part所要求事项的流程中开展开发工作。但是，ISO 26262的PART 8的12节和13节，分别叙述了“SW组件认定”和“HW组件认定”有关的条件和认定方法。只要符合此认定条件，即使有构成功能安全相关产品的要素，没有全部满足标准也可以。

例如，中间的复杂的HW组件和市面上在售的软件库等，即便不能证明遵循了各自对应的Part(HW话PART 5，SW话PART 6)的要求事项， 只要满足ISO26262的PART 8认定条件，并有采用方的认定的话也可以将其纳入功能安全相关产品中。在这种情况下，提供这些零件的供应商不需要建立功能安全流程。但是，因为这类零件的对应责任是由采用方承担，供应商应尽量采取安全措施，对安全的相应论证是必要的。

特别是对于中间的复杂的HW组件，用什么来确定中间的复杂度等问题实际很难明确，也是非常苦恼的地方。另外，关于SW组件，软件行业多年致力于再利用技术，也有很多基本没有拿到什么成果的难题，尽量不要考虑只从成本考量的再利用。不管怎样，对于认定的好处和伴随的风险/责任等，采用方和供应商都有必要慎重考虑。

ARIANE5事故

欧洲宇航机构(ESA)1996年发射“ARIANE5”爆炸的事故。据说直接原因就是再利用了ARIANE 4上有实际成果的软件。虽然是未经修正完全的再利用，不过，那个软件上的数据输入端传感器更新了，输入数据的格式不一样，软件发生误动作导致了事故。当然，这样的重大失误在最后都没有发现，过程中也有流程上的问题，不过，这也是软件的再利用带来的非常沉重的教训和事故。

表2整理了包括例外情况在内的供应商类型和各自需要的功能安全流程。

合同中不可或缺的流程要素二

本连载中，主要面向需要功能安全流程的中小供应商，所以例外的东西的讨论到此为止，我们回到ISO 26262：PART 8的5节“分散开发接口”。

开发接口协定（DIA）定义的流程，之前已经讲过，是与客户的合同上定义的最低限度的功能安全流程。在这项工作范围内，不仅包含产品开发的流程，也包括管理产品开发的管理流程，相关的支持流程，以及产品功能安全的监督和评价工作等。

表3是根据DIA的要求整理的功能安全流程。其中，“功能安全的必须流程”栏目中所示的东西，纯粹是样例，也可以是别的配置，或者别的名称的流程也没有什么问题。

这里只是从DIA的角度去看的，并不是搭建满足所有标准要求的功能安全流程。但是，主要的流程基本都有，可以将这些流程作为“骨头”，剩的部分作为“肉”来补充。如果已经存在功能安全基础流程，可以一边看他们之间的对应关系，一边将不足的流程和工作明确的列出来。

中小供应商的功能安全评价

在表3的流程中，从中小供应商的立场考虑功能安全流程稍微有些麻烦，那么功能安全评价呢？功能安全评价根据ISO 26262：PART 2中表2的定义，主要是评价“部件”的功能安全。因为中小供应商只构成部件当中的一个要素，难以判定部件全体的功能安全合格与否，所以直接接受标准要求是不现实的。通常，为了达到安全目标要求的安全方针，要从部件等级或车载系统的整体考虑，单纯的从构成要素角度去评价安全是有局限的。

对中小供应商来讲比较实际的是，不要负责功能安全评价的全部，而是只负责全体中的一部分。虽然不能评价系统全体的功能安全，不过，可以评价自己负责的产品是否按照要求采用正确的流程开发。例如，评价在本公司的负责范围内实施的验证活动的结果和功能安全审查的结果，从“安全要求有没有确实被落实”，“试验有没有充分地进行”，“未解决的问题是否还存在”等客观的角度来评价。客观的角度评价是发现开发人员主观因素影响很难注意到的问题的有效手段。

但是，具体的做法和评价角度、对象范围和评价的深度等要和合同对象(客户)协商调整，也有由客户来实施的情况。总之，关于这个话题的讨论，上次我们也有涉及到，在充分考虑自身组织情况的基础上，尽量考虑活动效果。

关于DIA的补充

这篇文章在标准要求的庞大的功能安全流程实施之际，以DIA为起点，阐述了从这个切入点切入所需要的流程要素。

但是，考虑到实际的业务，经常有人问DIA本身在哪些范围内是必须的，例如，在开发现场经常能看到，有时候并不是委托开发产品，而是为产品开发提供必要的技术服务(人员的服务)，这样的情况要怎样处理。

DIA是对产品进行分散开发，想法是责任各自承担，所以像对交付物不负责任这样的情况，DIA是很难的。而DIA不清楚的话，无法划分责任(责任由采购方承担)，所以，采购方面需要做相应的作业管理。

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