AutomotiveSPICE Vs. ISO 26262 | 差异点简析

鉴于很多朋友咨询关于ISO 26262和AutomotiveSPICE的区别,以及如何才能高效率的同时满足两种软件开发流程模型,我们特此整理本文进行了简单总结。FUSA Solutions 拥有ISO 26262和AutomotiveSPICE联合流程改进与评估的项目经验,欢迎大家踊跃交流。

版权声明:未经事先书面许可,任何第三方不得随意进行任何形式的转载,本文仅代表作者个人意见和经验总结。本文主要讨论AutomotiveSPICE V2.5版本和ISO 26262第一版之间的差异。

众所周知,ISO 26262道路车辆功能安全,主要是面向车载电控系统的可靠性相关标准,从两个方面进行解释,一个就是要把风险降低到可容许的等级之下,另外要针对可能发生的风险,确定4个阶段的安全的达成目标(ASIL)来采取必要的措施。另外一个大家经常提到,而且国内外OEM普遍关注的汽车电子软件开发流程就是AutomotiveSPICE,简称A-SPICE 。国内也有部分供应商,接到了来自海外OEM提出的A-SPICE的要求。甚至个别OEM要求必须同时具备ISO 26262开发流程和A-SPICE流程的双重认证,相关企业才能获得供应商的资格。

首先,AutomotiveSPICEISO 26262实施的良好基础。

一般来说,AutomotiveSPICE作为坚实的流程基础,主要目标是保证软件开发正常有序的进行。ISO 26262是在其基础上,通过功能安全的各种手段,充分保证产品的安全性与可靠性。有了这两个流程作为基本保证,加上相关的技术实现手段,研发高可靠性的电控系统才具备可操作性。不过需要注意的是,AutomotiveSPICE流程基础,并不是执行ISO 26262的流程的强制先决条件。

其次,量化的差异数据。

和AutomotiveSPICE流程相比,ISO 26262流程要求,总体约增加了20%~30%的工作量。这些新增工作量基本都和安全相关活动相关。详细的对比结果如下:

开发阶段

ISO 26262新增工作量

 系统开发阶段

新增—5%

拓展—65%

复用—30%

 软件开发阶段

新增—8%

拓展—75%

复用—17%

 

以下是ISO 26262与AutomotiveSPICE的主要差别:

  • 适用范围上的差别

ISO 26262 (主要关注整体生命周期)

AutomotiveSPICE (主要关注系统层和软件层)

关注车辆电子/电气系统的整个开发过程中功能安全需求的识别、分析、

实现、验证和管理过程。

关注车载软件的设计、开发、验证、管理和交付的过程。

从生命周期的角度来看,ISO26262还覆盖了产品的概念阶段和生产维护阶段。

 

 

 

  • 目标范围的差别

ISO 26262 (主要关注安全文化)

AutomotiveSPICE (主要关注质量文化)

一切以安全需求,安全设计实现,安全验证等活动为核心,

主要保证驾乘人员的人身安全

以QC / QA为核心

关注和应对电子/电气系统在整个安全生命周期内的系统性失效和硬件随机失效风险。

 

并通过合理的 (成本可控),合适的 (无论通过硬件还是软件,故障诊断和故障处理策略

一定要完善)的方式,实现系统的高可靠性,同时兼顾可用性要求。

关注和实现在预算内按期交付满足客户需求的高质量软件产品。目前无论是V2.5版本还是V3.0版本,没有包含对硬件开发的要求。

不过熟悉ISO26262流程图的朋友们,肯定觉得AutomotiveSPICE V3.0的过程域图很眼熟,估计下一版AutomotiveSPICE极有可能加入硬件要求。

 

  • 实施层面的差别

ISO 26262的要求是“实施”层面的,是在ASPICE的基础上增加了实施层面的实施方法和规则的要求。

AutomotiveSPICE的要求是过程层面的,仅要求了做什么。

备注:满足AutomotiveSPICE的要求是成功实施ISO 26262的良好基础。

 

具体细节上的差别 (ISO 26262对于ASPICE的新增内容)

MAN管理过程方面的基本区别

  • --要求建立安全文化 (e.g. 进度要求和流程要求有矛盾,如何协调)
  • --组织成员具备安全管理的相关技能和资质 (推荐核心人员具备功能安全经理或功能安全专家资格)
  • --新增安全职责要求
  • --新增安全计划要求 (该文件也是功能安全管理的一个核心文档)
  • --要求建立安全档案(Safety Case)
  • --要求实施确认评审
  • --要求实施功能安全审核
  • --要求实施功能安全评估
  • --新增生产发布后的安全安全管理

 

SW软件需求分析方面的基本区别

  • --确定软件安全需求
  • --细化软硬件接口(HSI)
  • --软件需求的ASIL等级分解
  • --对软件安全需求和细化的软硬件接口进行评审验证
  • --具体实施层面,如软件需求规范性,如:需求标记方法、需求的唯一标识和ASIL属性等
  • --软件需求管理,如:软件需求集合的结构、软件需求验证的方法等

 

SW软件架构和单元设计方面的区别

  • --要求实施安全分析
  • --安全机制设计
  • --识别模块的开发类型和ASIL等级
  • --实施要求
  • --软件架构设计的标记法
  • --软件架构设计的原则
  • --软件架构设计的验证方法

 

SW软件集成测试方面的基本区别

  • --软件集成测试的方法(如:基于要求的测试、资源消耗测试等)
  • --软件集成测试用例的抽出方法(如:要求分析、边界值、等价类等)
  • --软件集成测试的覆盖度(函数覆盖、调用覆盖)
  • --软件集成测试的环境要求
 
除了以上的具体议题,我们下面聊聊AutomotiveSPICE V3.0的事情。
 
首先看一下ISO 26262的V模型:

 
我们再来看一下AutomotiveSPICE V3.0版本的流程域构成:
 
 
其实不用细说也能大概看出来,AutomotiveSPICE V_3.0版本看起来,和ISO 26262的总体框架相似度更高。原ENG工程域被拆分为SYS系统工程域和SWE软件工程域,整体的流程架构更清晰,更向ISO 26262靠近,估计下一版有准有可能会看到SYS下面除了SWE软件工程域之外,又多出来一个HWE硬件工程域出来。
 
其他的既有差异点,如适用范围上的差别,目标范围的差别,实施方式的差别以及一些具体的细节对比这里就不再描述了。