ASPICE和ISO26262有什么关系

ASPICE和ISO 26262是针对汽车领域不同方面的标准。ASPICE提供了软件开发和维护过程的优异实践，包括质量管理、项目管理等方面；ISO 26262标准涉及到汽车电子系统的整个生命周期，包括开发、测试、维护等方面。

一、ASPICE和ISO26262的关系

ASPICE（Automotive SPICE）是一种为汽车领域的软件开发和维护提供优异实践的过程框架。它定义了一组用于评估和改进汽车软件开发过程的标准，并包括一个过程评估模型（Process Assessment Model）和一个成熟度模型（Capability Maturity Model），用于检查进程的质量、进展和改进方向。ISO 26262是一套汽车电子安全标准，为汽车安全相关电子系统的功能安全性提供了指南。虽然ASPICE和ISO 26262是针对不同方面的标准，但它们之间存在紧密的关系。ISO 26262标准涉及到汽车电子系统的整个生命周期，包括系统开发、测试和维护等方面；而ASPICE提供了软件开发和维护过程的优异实践，包括质量管理、项目管理、需求分析、软件设计等方面。在实际应用中，ASPICE和ISO 26262通常是同时使用的。基于ASPICE的优异实践能够帮助汽车电子系统的开发人员设计和实现高质量、可靠、安全的软件，以满足ISO 26262标准对于汽车电子系统安全的需求。以这种方式实现，既满足了软件开发过程规范化的需求，也满足了汽车电子系统安全的需求。

二、ASPICE的内容

ASPICE标准包含3个部分(请参考下图)，分别为流程参考模型、量测架构、流程评估模型。其中：

过程参考模型与过程评估模型的关系

流程参考模型(Process reference model)： (Automotive SPICE 相关) 根据专案执行所需，共定义了32个流程，并且详加定义了各流程的范围、目的、主要产出。
量测架构(Measurement framework)：主要继承ISO/IEC 33020中的定义，包含能力等级(各定义了6个等级)、流程属性、评分规模、评分方法、合计方法、流程能力等级模型等。
流程评估模型(Process assessment model)： (Automotive SPICE 相关) 针对各流程定义了流程能力指标及流程实施指标。

评估人员将基于企业所选定的流程范围(X轴)，并参考量测架构所定义的能力维度(Y轴)及流程评估模型所定义的能力指标与实施指标来逐一为每个流程进行评分。

三、ISO26262的制定过程

功能安全标准化的运动起源于20世纪90年代。上世纪70年代开始，随着各种现代化及其的使用，以及工业生产过程的自动化程度越来越高，以电气、电子、可编程电子产品的大量应用为标志的现代化控制系统越来越多的渗透到各个领域，参与着各种控制过程。

但是，工业文明在给人类带来利益的同时，也带来了灾难。由于系统设计不合理、设备元器件故障或失效、软件系统的故障导致的事故、人身伤害、环境污染，越来越频繁的危及着我们的生命安全和赖以生存的环境。人们开始认识到，必须采取措施，用标准和法规来规范领域内安全相关系统的使用，使技术在安全的框架内发展，使人类既能尽可能享受新技术带来的安全和舒适，同时又能掌控危险。功能安全标准研究从此展开。

然而，安全控制系统或设备执行安全功能时的可靠性问题，限制了用户使用新技术的积极性。由于没有公认的评价体系，制造商很难说服用户使用新技术，尤其在关系人身财产安全的重要领域使用新技术。另外，不同行业对安全要求的不同，也限制了安全设备的产业化生产规模。制造商迫切需要一个公认的标准来建立一个与用户对接的公共平台。

于是，2000年5月，国际电工委员会正式发布了IEC61508标准，名为《电气/电子/可编程电子安全相关系统的功能安全》。IEC61508中，系统中的安全设备（减少风险的手段）由中继控制器或PLC（Programmable logic控制器）等设备构成，我们把安全设备将实现其安全功能的可靠性的概率称为安全完整性水平，即SIL（SAFety Integrity Level）。换句话说，基于这个等级标准，即，如果与构成安全系统的部件的故障率低，则由此构成的整个安全系统的故障率也是低的。

但是，有一种观点认为，在SIL定义中加入概率因素并不合适的。为什么不合适呢？那是因为功能安全标准不仅涉及了硬件部分，还涉及了软件部分。仅论硬件故障发生的概率，除了初始故障和损耗故障以外，偶发故障基本是随机发生的，如果把设计错误分开，那么加入概率因素是非常合适的。与此相对的软件故障可不是随机的了，所以软件故障(bug)是很难去计算其发生的概率的。例如，如果软件的设计中混入了bug，只要其发生路径和条件具备，那么故障的发生概率就是百分百。

针对这个问题，对IEC 61508重新修订制定了ISO 26262标准。2011年11月，ISO 26262正式颁布。ISO 26262 不同于 IEC 61508，它“不是一个可靠性标准”，它并没有为可接受失效概率设定准确的数字。ISO 26262基于概率论的定量危害分析仅限适用于硬件，其次，基于目标产品的使用条件和使用方法，针对整个系统进行危害分析和风险评估，识别出系统危害并对危害的风险等级——ASIL等级（Automotive SAFety Integration Level，汽车安全完整性等级）进行评估。IEC 61508定义了安全完整性等级 (SIL)，而 ISO 26262 则定义了汽车安全完整性等级 (ASIL)。

ASIL有四个等级，分别为A，B，C，D，其中A是最低的等级，D是较高的等级。然后，针对每种危害确定至少一个安全目标，安全目标是系统的较高级别的安全需求，由安全目标导出系统级别的安全需求，再将安全需求分配到硬件和软件。ASIL等级决定了对系统安全性的要求，ASIL等级越高，对系统的安全性要求越高，为实现安全付出的代价越高，意味着硬件的诊断覆盖率越高，开发流程越严格，相应的开发成本增加、开发周期延长，技术要求严格。

延伸阅读1：企业导入ASPICE的方法