鉴于很多朋友咨询关于ISO 26262和AutomotiveSPICE (ASPICE/A-SPICE) 的区别，以及如何才能高效率的同时满足两种软件开发流程模型，我们特此整理本文进行了简单总结。FUSA Solutions 拥有ISO 26262和AutomotiveSPICE联合流程改进与评估的项目经验，欢迎大家踊跃交流。
版权声明：未经事先书面许可，任何第三方不得随意进行任何形式的转载，本文仅代表作者个人意见和经验总结。本文主要讨论AutomotiveSPICE (ASPICE/A-SPICE) V2.5版本和ISO 26262第一版之间的差异。
众所周知，ISO 26262道路车辆功能安全，主要是面向车载电控系统的可靠性相关标准，从两个方面进行解释，一个就是要把风险降低到可容许的等级之下，另外要针对可能发生的风险，确定4个阶段的安全的达成目标(ASIL)来采取必要的措施。另外一个大家经常提到，而且国内外OEM普遍关注的汽车电子软件开发流程就是AutomotiveSPICE，简称A-SPICE 。国内也有部分供应商，接到了来自海外OEM提出的A-SPICE的要求。甚至个别OEM要求必须同时具备ISO 26262开发流程和A-SPICE流程的双重认证，相关企业才能获得供应商的资格。
首先，AutomotiveSPICE (ASPICE/A-SPICE) 是ISO 26262实施的良好基础。
一般来说，AutomotiveSPICE作为坚实的流程基础，主要目标是保证软件开发正常有序的进行。ISO 26262是在其基础上，通过功能安全的各种手段，充分保证产品的安全性与可靠性。有了这两个流程作为基本保证，加上相关的技术实现手段，研发高可靠性的电控系统才具备可操作性。不过需要注意的是，AutomotiveSPICE流程基础，并不是执行ISO 26262的流程的强制先决条件。
其次，量化的差异数据。
和AutomotiveSPICE (ASPICE/A-SPICE) 流程相比，ISO 26262流程要求，总体约增加了20%～30%的工作量。这些新增工作量基本都和安全相关活动相关。详细的对比结果如下：
|
开发阶段 |
ISO 26262新增工作量 |
|
系统开发阶段 |
新增—5% 拓展—65% 复用—30% |
|
软件开发阶段 |
新增—8% 拓展—75% 复用—17% |
以下是ISO 26262与AutomotiveSPICE (ASPICE/A-SPICE) 的主要差别：
- 适用范围上的差别
|
ISO 26262 (主要关注整体生命周期) |
AutomotiveSPICE (主要关注系统层和软件层) |
|
关注车辆电子/电气系统的整个开发过程中功能安全需求的识别、分析、 实现、验证和管理过程。 |
关注车载软件的设计、开发、验证、管理和交付的过程。 |
|
从生命周期的角度来看，ISO26262还覆盖了产品的概念阶段和生产维护阶段。 |
|
- 目标范围的差别
|
ISO 26262 (主要关注安全文化) |
AutomotiveSPICE (主要关注质量文化) |
|
一切以安全需求，安全设计实现，安全验证等活动为核心， 主要保证驾乘人员的人身安全 |
以QC / QA为核心 |
|
关注和应对电子/电气系统在整个安全生命周期内的系统性失效和硬件随机失效风险。
并通过合理的 (成本可控)，合适的 (无论通过硬件还是软件，故障诊断和故障处理策略 一定要完善)的方式，实现系统的高可靠性，同时兼顾可用性要求。 |
关注和实现在预算内按期交付满足客户需求的高质量软件产品。目前无论是V2.5版本还是V3.0版本，没有包含对硬件开发的要求。 不过熟悉ISO26262流程图的朋友们，肯定觉得AutomotiveSPICE V3.0的过程域图很眼熟，估计下一版AutomotiveSPICE极有可能加入硬件要求。 |
- 实施层面的差别
|
ISO 26262的要求是“实施”层面的，是在ASPICE的基础上增加了实施层面的实施方法和规则的要求。 |
AutomotiveSPICE的要求是过程层面的，仅要求了做什么。 |
备注：满足AutomotiveSPICE(ASPICE/A-SPICE) 的要求是成功实施ISO 26262的良好基础。
具体细节上的差别 (ISO 26262对于ASPICE的新增内容)
MAN管理过程方面的基本区别
- --要求建立安全文化 (e.g. 进度要求和流程要求有矛盾，如何协调)
- --组织成员具备安全管理的相关技能和资质 (推荐核心人员具备功能安全经理或功能安全专家资格)
- --新增安全职责要求
- --新增安全计划要求 (该文件也是功能安全管理的一个核心文档)
- --要求建立安全档案(Safety Case)
- --要求实施确认评审
- --要求实施功能安全审核
- --要求实施功能安全评估
- --新增生产发布后的安全安全管理
SW软件需求分析方面的基本区别
- --确定软件安全需求
- --细化软硬件接口(HSI)
- --软件需求的ASIL等级分解
- --对软件安全需求和细化的软硬件接口进行评审验证
- --具体实施层面，如软件需求规范性，如：需求标记方法、需求的唯一标识和ASIL属性等
- --软件需求管理，如：软件需求集合的结构、软件需求验证的方法等
SW软件架构和单元设计方面的区别
- --要求实施安全分析
- --安全机制设计
- --识别模块的开发类型和ASIL等级
- --实施要求
- --软件架构设计的标记法
- --软件架构设计的原则
- --软件架构设计的验证方法
SW软件集成测试方面的基本区别
- --软件集成测试的方法（如：基于要求的测试、资源消耗测试等）
- --软件集成测试用例的抽出方法（如：要求分析、边界值、等价类等）
- --软件集成测试的覆盖度（函数覆盖、调用覆盖）
- --软件集成测试的环境要求
我们再来看一下AutomotiveSPICE (ASPICE/A-SPICE) V3.0版本的流程域构成：
