本连载以中小供应商为对象，主要介绍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组件，软件行业多年致力于再利用技术，也有很多基本没有拿到什么成果的难题，尽量不要考虑只从成本考量的再利用。不管怎样，对于认定的好处和伴随的风险/责任等，采用方和供应商都有必要慎重考虑。