ASPICE 和 ISO 26262：这一结合对汽车软件开发有何影响

作为汽车行业创新的主要驱动力，软件开发一直在不断改进。而且，这一创新是由所有利益相关者（主机厂、tier-1、技术服务商）共同进行的，因此有必要建立标准框架将它们联系在一起。对于软件开发的定义、实施和过程评估，这些利益相关者之间的协调对于实现无缝协作至关重要。Automotive Software Performance Improvement and Capability dEtermination（ASPICE）正是为此提供了一个桥梁和框架。而ISO 26262标准规定的道路车辆的功能安全增加了一个维度到这一标准化过程中。除了提高软件质量之外，汽车系统的安全方面也变得非常重要。ISO 26262现在已经成为一种事实上的汽车功能安全标准，所有道路车辆都必须遵守。

我们在这里讨论了两个不同的概念：一个是关注整体软件质量，另一个是处理安全方面。它们之间有什么关联？ASPICE和ISO 26262是否相互补充？它们可以共存吗？让我们试图找到一些答案！但首先，我们必须了解ASPICE和ISO 26262各自的内容。

  ASPICE在提高汽车应用程序质量方面的作用

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

采用ASPICE的直接影响是对过程的改进，从而提高了软件的质量。在供应商选择过程中，原始设备制造商可以使用ASPICE框架来评估供应商的能力和质量。另一方面，ASPICE也可以成为供应商提高其质量水平的框架。

ASPICE是一个具有过程维度和过程能力维度的双重模型。ASPICE识别不同的过程，如需求引出、系统需求分析、过程管理等。本质上，这些过程不过是在软件开发生命周期中执行的活动。您可以轻松地将过程，如需求分析、架构设计、单元测试等，识别为V模型的一部分。过程维度将这些过程分组，例如系统工程过程组和管理过程组等。这种分类采用了称为过程参考模型的模型形式。在这里，每个过程都根据其范围和功能目标进行定义。

现在，已经捕获了过程维度，需要测量过程能力。根据ISO 15504标准，为每个过程定义了从级别0到5的能力级别。

级别0 – 不完整：开发过程不完整或没有妥善记录。

级别1 – 执行：过程达到其目的；然而可能存在一些间隙。

级别2 – 管理：过程以受控的方式实施，即它们经过计划和监测。

级别3 – 确立：过程得到了良好的建立，文档已经在整个供应链上得到认真遵循。

级别4 – 可预测：过程在定义的限制内实施，其输出可以预测。

级别5 – 创新：在可预测的过程中不断改进，以应对不时出现的新挑战。

过程能力级别由ISO 15504标准明确定义的过程属性（PA）来确定。这些属性包括：

这些属性各自涉及过程能力级别的特定方面。这些PA按照以下划分进行评级：

N（未实现）：结果未实现或未被执行。

P（部分实现）：部分预期结果已经实现，但能力未能完全实现。

L（大部分实现）：增加了达成预期结果的可能性，但不能确定是否能够达到预期的质量、时间和预算目标。

F（完全实现）。

最终评估是通过使用过程评估模型（PAM）来进行的。下面是一个示例PAM：

  ISO 26262和汽车功能安全方面

汽车内部有许多部件是安全关键的，如电子转向系统、防抱死制动系统、安全气囊、动力总成电子控制单元等。

通过安全关键，我们指的是这些部件的故障会对驾驶员或乘客的生命构成风险。

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

ISO26262标准是一套规范产品生命周期的步骤，涵盖了软件、硬件和系统层面。ASIL（汽车安全完整性级别）是一种分类方案，用于表示软件或硬件组件的安全关键性。

ASIL有四个类别 - ASIL A，ASIL B，ASIL C和ASIL D。ASIL A表示最不关键的级别，而D表示最关键的级别。

  当ASPICE遇到ISO 26262 

ASPICE覆盖了整个系统开发，这也是为什么ASPICE提供了一个理想的框架来实施ISO 26262标准的原因。

正如上图所示，ISO 26262生命周期可以与Automotive SPICE遵循的V模型相匹配。

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

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

ISO 26262规定的安全生命周期与ASPICE同时进行。在V周期的每个阶段，ISO 26262标准建议的某些分析都与ASPICE过程一起进行。例如，危险分析作为风险管理（ASPICE）的扩展进行。还引入了更多的分析，如FMEA和FMEDA，以推导安全目标、FIT（时间内的故障）以及某些硬件指标，如SPFM、LFM和PMHF。

此外，系统要求规范还将包括安全要求。验证和验证过程也将遵循ISO 26262标准中提到的方法。这个图表使ISO 26262和ASPICE之间的重叠关系更加清晰。

  ASPICE 3.1版本在与ISO 26262整合方面有哪些变化 

ASPICE 3.1版本在与ISO 26262的集成方面进行了一些增强，通过实施ASPICE，也可以实现ISO 26262的主要部分。

需求引出根据ASPICE相当于ISO 26262标准中的项目定义。在ASPICE的最新版本中，需求引出提供了强有力的支持，以执行项目定义。这意味着这两个活动的很大部分可以合并，从而减少工作量和时间。

同样，ASPICE中有一些过程对其在ISO 26262实施中的对应活动提供了中等级别的支持。一个例子是软件单元验证，其中一些指南重叠，而其他则不重叠。大多数ASPICE过程都属于中等支持类别，例如系统架构设计、集成测试等。

然而，还有一些ISO 26262的活动距离ASPICE过程相对较远。这些包括功能安全概念和技术安全要求规范。

总体而言，整个汽车行业都在推动ASPICE和ISO 26262的集成。但是，在集成ASPICE和ISO 26262时仍然存在一些固有挑战。让我们看看这些挑战。

  ASPICE和ISO 26262整合面临的挑战以及如何克服这些挑战

将ISO 26262和ASPICE集成可能具有挑战性，原因包括范围、术语和评估标准的差异。

ISO 26262是一个标准，要求采用各种测试方法、软件架构设计和实施指南等，以确保在系统级别满足功能安全要求。与此不同，ASPICE更侧重于提高汽车软件的质量，不仅在系统级别，还在项目和组织级别。

这些根本差异因此导致了在需要同时实施ASPICE和ISO 26262标准的情况下出现的挑战。让我们探讨这些挑战：

这些挑战必须由项目中的功能安全经理和ASPICE顾问共同应对。以下是一些建议，说明他们如何应对这些挑战：

  展望未来

ASPICE涵盖了软件开发的广泛方面，而ISO 26262可以扩展其安全方面。尽管这两个标准在成本、时间等方面存在许多不同之处，但它们也有一些相似之处，包括配置和更改管理以及承诺在工作产品之间实现双向可追溯性等过程领域。将ISO 26262功能安全标准的要求融入ASPICE汽车软件开发流程中，并以此指导汽车软件开发实践，会大幅改善汽车软件开发品质、开发效率以及提高产品的安全性。