ASPICE是一个为建立和评估汽车软件开发过程提供框架的标准。我们在这里讨论了两个不同的概念，一个负责全局的概念。软件质量而另一个负责处理安全方面。它们之间有什么关系？ASPICE和ISO 26262

  

ASPICE和ISO26262这一联合如何影响汽车软件开发前景

作为汽车行业创新的主要推动力，软件开发正处于不断改进的状态。事实上，创新是由所有利益相关者(原始设备制造商、一级供应商、技术供应商)进行的，因此有必要制定约束所有这些利益相关者的标准框架。在软件开发的定义、实现和过程评估方面，这些利益相关者之间的协调对于无缝协作至关重要。A机车S常软件P服务度I改进和C可达性dE终止(ASPICE)就是旨在实现这种协调的框架之一。

规定道路车辆的功能安全ISO26262标准为这一标准化增加了一个维度。除了提高软件的质量外，汽车系统的安全方面也非常重要。ISO 26262现在是一个事实上的汽车功能安全标准，所有道路车辆必须遵守。

我们在这里讨论了两个不同的概念，一个负责全局的概念。软件质量而另一个负责处理安全方面。它们之间有什么关系？ASPICE和ISO 26262相辅相成吗？它们能共存吗？我们试着找出一些答案吧！但首先，我们必须理解ASPICE和ISO 26262的个人能力。

ASPICE在提高汽车应用质量中的作用

ASPICE是由一个由欧洲汽车制造商组成的集团在ISO/IEC 15504中定义的。ASPICE是一个为建立和评估汽车软件开发过程提供框架的标准。

采用ASPICE的直接影响是改进过程，从而影响软件的质量。在供应商选择过程中，OEM可以使用ASPICE框架来评估供应商的能力和质量。另一方面，ASPICE可以被证明是供应商将质量提升到更高水平的框架。

ASPICE是一个二维模型，包括过程维度和过程能力维度.

ASPICE识别了不同的过程，如需求激发、系统需求分析、过程管理等。本质上，这些过程只不过是在软件开发生命周期中要执行的活动。您可以很容易地将需求分析、体系结构设计、单元测试等过程识别为V模型的一部分。过程维度将过程划分为系统工程组、过程组和管理过程组等组。这种分类的形式是一个称为过程引用模型的模型。在这里，每个过程都是根据其范围和功能目标来定义的。

ASPICE识别了不同的过程，如需求激发、系统需求分析、过程管理等。本质上，这些过程只不过是在软件开发生命周期中要执行的活动。您可以很容易地将需求分析、体系结构设计、单元测试等过程识别为V模型的一部分。过程维度将过程划分为系统工程组、过程组和管理过程组等组。这种分类的形式是一个称为过程引用模型的模型。在这里，每个过程都是根据其范围和功能目标来定义的。

既然已经捕获了流程维度，就需要度量流程能力。对于每个流程，ISO 15504标准定义了从0级到5级的能力级别。

能力水平由ISO 15504标准中明确定义的过程属性(PA)决定。这些属性如下：

• 工艺性能

• 绩效管理

• 工作产品管理

• 过程定义

• 流程部署

• 过程测量

• 过程控制

• 工艺创新

• 工艺优化

这些属性中的每一个都与流程能力级别的特定方面有关。这些考绩制度的等级如下：

N(未实现)：未实现或未执行的结果

P(部分实现)：取得了一些预期成果，但能力尚未全部实现

L(基本实现)：实现成果的可能性增加，但无法确定实现预定的质量、时间和预算目标。

F(已完全实现)： 

最后的评估使用过程评估模型执行。下面显示了一个PAM示例：

ISO 26262与汽车功能安全

汽车内部的许多部件是安全临界如电子转向系统、防抱死制动系统、气囊、动力总成ECU等.

由于安全问题，我们暗示这类零件的故障会对司机或乘客的生命构成危险。

ISO 26262是一个标准，它定义了在设计、开发和测试道路车辆的所有电气和电子部件时实施安全实践的安全生命周期。

ISO 26262标准是一套在软件、硬件和系统级别上规范产品生命周期的步骤。AISL(汽车安全完整性等级)是一种软件或硬件组件的分类方案，表示其安全性-临界性。

ASIL等级有四类-ASIL A、ASIL B、ASIL C和ASIL D。

当ASPICE符合ISO 26262标准时

ASPICE涵盖了整个系统的开发过程，这也是ASPICE为实现ISO 26262标准提供一个理想框架的原因之一。

ISO 26262带来的附加项目主要与概念阶段有关。它们包括：

• 项目定义它是系统、子系统、功能依赖项和各种此类属性的列表.项目定义文档中包含的信息作为Hara过程的输入。

• 失效模式效应分析(FMEA)FMEA是一种归纳分析方法，用来找出故障的原因和后果。它还有助于识别功能需求和非功能需求，而这些需求在Hara期间可能还没有被识别。

• 故障模式、影响和诊断分析(FMEDA)故障模式、影响和诊断分析(FMEDA)是推导硬件体系结构度量的理想方法，如PMHF(概率硬件故障度量)、SPFM(单点故障度量)和LFM(潜在故障度量)。

• 故障树分析：故障树分析(FTA)是一个用布尔逻辑描述故障根的演绎故障分析的例子。

• 危险分析和风险分析(Hara)*HARA的目的是查明可能导致E/E系统危害的故障，并评估与之相关的风险。

与ISO 26262和ASPICE一起，大约有250个工作产品和60个过程需要处理，这确实是一个巨大的工作量。

ISO 26262规定的安全生命周期与ASPICE同时进行。在V周期的每一个阶段，ISO 26262标准推荐的某些分析都与ASPICE流程一起进行.例如，风险分析是对风险管理(ASPICE)的扩展。更多的分析，如FMEA和FMEDA被引入到安全目标，失败的时间(FIT)和某些硬件指标，如SPFM，LFM和PMHF。

此外，系统需求规范还将包括安全要求。核查和验证过程也将遵循ISO 26262标准中提到的方法。

前路

ASPICE涵盖了软件开发的广泛方面，而ISO26262可以扩展其安全方面。这两个标准在许多方面是不同的，比如成本和时间影响，评估等等。然而，它们有很多相似之处，包括配置和变更管理等过程领域，以及实现工作产品之间双向可追溯性的承诺。

还提供了一些工具和模板，使ASPICE和ISO 26262的集成更易于开发和遵循团队。功能安全咨询组织利用这些工具和模板来帮助原始设备制造商和供应商实现所需的合规。