01、摘要
随着汽车电动化、智能化和互联化不断演进，汽车的电子电气架构得到持续升级，而汽车硬件方面逐渐趋向标准化。与此同时，汽车软件呈现出不断多样化和日益复杂的趋势。在这个大背景下，传统的软件开发流程已经无法满足这一需求，我们需要建立一套合理的软件开发体系，以更好地应对不断增长的软件复杂性。
ASPICE的核心背景是应对汽车行业中软件和电子系统的增长，提高产品质量和安全性，确保全球供应链中的一致性，以及应用最佳的软件工程实践。ASPICE的出现是为了解决这些复杂性和挑战，以确保汽车软件和电子系统满足高标准，并降低潜在的风险，成为指导汽车软件开发过程的重要工具。
02、什么是ASPICE
ASPICE最早源于能力成熟度模型集成CMMI(Capability Maturity Model Integration)，后来由不同的国际组织及机构联合发布形成SPICE( Software Process Improvement and Capability Determination)，最终针对汽车行业的需求，于2005年，由德国的汽车制造商和供应商，共同成立的Automotive SPICE Interest Group提出针对汽车行业的Automotive SPICE。
ASPICE（Automotive Software Process Improvement and Capability Determination）是一种软件过程能力评估模型，旨在评估和改进汽车行业的软件开发过程。它提供了一套标准和指南，帮助组织评估其软件开发过程的成熟度和质量，并提供改进的方法和最佳实践。
03、ASPICE的主要目标是什么
1.质量提升：ASPICE旨在帮助组织提高车载软件质量，降低缺陷率，并确保汽车电子系统的可靠性。
2.安全性：由于汽车电子系统的复杂性和对安全的要求，ASPICE强调开发安全性高的软件，以防止潜在的危险情况。
3.一致性：ASPICE鼓励组织建立一致的车载软件开发和维护过程，以确保汽车电子系统产品和服务的一致性。
4.成本控制：通过改进过程，ASPICE可以帮助组织降低车载软件开发和维护的成本。
04、为什么ASPICE对OEM和汽车供应商很重要？
ASPICE是一项强大的标准，能够在组织、项目和系统级别来评估公司的流程，以便汽车供应商和OEM能够持续监控并改进工作方式。
企业做ASPICE有两个方面作用: OEM对供应商有准入门槛，如ASPICE CL2证书，这个是我们很多企业做ASPICE的一个主要原因；另一个方面是提高我们开发人员的能力，改善软件质量。
对于OEM来说，遵循ASPICE标准意味着他们能对供应商的流程质量水平进行评估，进而轻松选出能够满足其需求的供应商。对于供应商来说，遵循ASPICE标准能够保证他们满足客户需求，同时提高流程质量。这能够提升产品的整体质量，也有可能缩短上市时间、降低开发成本。
ASPICE标准的目标是帮助企业在各个阶段定义和整合汽车软件开发的最佳实践，包括设计、审查、开发、测试和验证。在根据ASPICE指南来指定每个流程的最佳实践，并展示您如何实施这些实践后，您就可以准备进行ASPICE评估了。
ASPICE对现有的安全和质量管理标准和指南进行了补充，例如侧重于功能安全的ISO 26262、侧重于网络安全工程的ISO 21434等。另外，还有一个针对网络安全的 Automotive SPICE版本，用于指导汽车制造商识别和管理供应链中的网络安全风险。
05、ASPICE的关键组成部分
ASPICE框架包含几个关键的组成部分，这些部分共同为软件开发提供了一种规范化的方法：
流程要求：ASPICE定义了软件开发的关键流程，从项目管理到验证和确认。每个流程都有明确的指导和要求，有助于确保开发在每个阶段都是有序的、规范的。
能力级别：ASPICE将软件开发能力划分为不同的级别，从Level 0到Level 5。每个级别代表了开发过程的不同成熟度和能力水平。企业可以根据实际情况逐步提升能力级别，从而逐步改进软件开发过程。
过程指南：ASPICE提供了详细的过程指南，包括流程的输入、输出、活动和工作产品。这些指南有助于团队理解在每个阶段应该执行的任务，以及如何确保质量和合规性。
Automotive SPICE 4.0
06、ASPICE 4.0相对ASPICE 3.1有了哪些变化？
ASPICE 4.0于2023年11月发布，较ASPICE3.1总体的变化就是涵盖内容更加全面完整，过程域更加精简实用，文字描述更加准确适用。
具体来说，首先，Automotive SPICE® 4.0删除了10个过程，增加了3个过程组和10个过程：
- 删除很少被使用的ACQ.3, ACQ.11 - ACQ.15, SPL.1
- 删除与SUP.1有重复的SUP.2, SUP.4
- 删除与SUP.8有重复的SUP.7
- 增加VAL 验证过程组，1个过程（VAL.1）
- 增加HWE 硬件工程过程组，4个过程（HWE.1-HWE.4）
- 增加MLE 机器工程过程组，5个过程（MLE.1-MLE.4,SUP.11）
同时，在本次ASPICE 4.0中进行还了修正和明确了之前ASPICE 3.1的实施过程中经常会遇到的一些困惑和模糊的内容，让ASPICE标准与项目实践更加贴合适用，具体的变化在后续技术文章中再给大家带来分享。
07、企业导入ASPICE选择ASPICE 4.0还是 ASPICE 3.1？
目前大多数的企业的ASPICE都是按照ASPICE 3.1标准，但现在我们新接触的大部分客户都趋向于选择ASPICE 4.0。
ASPICE 3.1这个标准有32个过程域，根据不同背景颜色有不同的过程组；32个过程对企业选择也比较难，VDA推荐了16个过程组，红框里面作为ASPICE的一些基本过程，如果企业不知道做哪些过程，可以以这16个过程为基础，当然，企业可以根据自己来选择增加或者减少哪些过程组；比如ACQ.4，如果我们不涉及外包，我们可以把这个过程去掉。比如想增加一些过程：Verification或Joint review或文档管理，当然也可以加里面，又比如MAN.5和MAN.6，也可以加进来。也就是说在做ASPICE的时候这些过程是可以自己选择的。
08、企业导入ASPICE的步骤有哪些？
企业如果要导入ASPICE，按照以下流程进行：
- 对当前项目的开发情况进行差距分析（包括流程、工具、资源）；
- ASPICE标准培训；
- 按照产品的特性以及认证的等级需求制定流程、模板、检查单；
- 按照上一步骤确定的流程执行项目开发；
- 提供相关证据，证明按照要求实施了ASPICE的流程，提供给评估方进行评估，发放产品及流程证书及人员证书。
如果需要通过认证，一般国内外主机厂在对供应商审核时通常考察16个过程域。ACQ.4、SYS.2、SYS.3、SYS.4、SYS5、SWE.1、SWE.2、SWE.3、SWE.4、 SWE.5、SWE.6、SUP.1、SUP.8、SUP.9、SUP.10、MAN.3。认证主要需要提供相关的实施证据，当满足不同等级的审核要求后，将会颁发相关等级的证书。真实的项目中根据项目周期的长短，会对标准流程中具体过程进行适当的裁剪。ASPICE流程是指导团队开发过程中如何保证代码的交付质量，可以根据项目的周期、团队的人员数量等外界因素进行适当的裁减，灵活运用。
09、ASPICE的评估对象及有效期
ASPICE评估对象是项目，而不是产品或公司体系。ASPICE评估只能证明一个公司某个项目在某个时间段的过程能力情况。假设一个公司项目通过了ASPICE CL2评估时，说明该公司被评估项目A的相关被评估过程达到了CL2能力度等级。但并不能说明该公司其他项目B也达到了CL2能力度级别。
被评估项目如果没有发生变更（包括开发过程调整、组织结构调整、人员替换等），则可以认为评估结果在3年之内是有效的。
在主机厂考察供应商时，如果供应商在几个月前的项目中实施了一次ASPICE评估结果，则主机厂可能会认为企业目前的过程能力可接受。但如果供应商在几年前的项目中实施了一次ASPICE评估结果，则主机厂可能不会接受。这个具体可接受的时间期限依不同OEM而定，不能一概而论。
10、ASPICE标准与功能安全ISO 26262标准的关系
ASPICE标准提供了对产品开发过程的要求，ISO26262功能安全不仅提供了过程要求，还对产品的技术需求提出了要求，例如要求不同等级的硬件指标达到的值。
ASPICE流程包括主要生命周期的系统过程域和软件过程域、支持生命周期过程域，其聚焦点是软件。而功能安全ISO26262是产品全生命周期开发提出了要求，聚焦点是产品。ASPICE 4.0 还增加了硬件工程、机器学习过程组和确认过程组。其中：
机器学习过程组目的是为了应对人工智能（AI）在汽车功能设计中的普及，以及车辆功能和设计与开发流程自动化程度的提高。这个过程组在实际应用过程中可以和ADAS/AD智驾系统功能安全ISO 26262开发相结合，从需求导入、架构设计、软硬件设计进行融合。
硬件过程组作为主要生命周期过程组之一被添加到标准中。这一变化反映了硬件在现代汽车机电控制系统中的广泛应用，同时也是对 ASPICE 以前版本中缺乏硬件工程专用特定过程的回应。将硬件工程流程添加到模型中可让开发人员实现对系统的全面覆盖，并使 ASPICE 4.0 更紧密地与行业中的其他主要标准保持一致，如 ISO 26262: 2011《道路车辆-功能安全》和 ISO/SAE 21434:2021《道路车辆-网络安全》。
确认过程组 Validation过程目的是为了促进从终端用户使用的角度，来Validate产品是否满足intended use，并且和其他的行业标准进行了对齐，如：
ISO26262:2018 Part 4-8 Safety validation, ISO/SAE 21434:2021 Clause 11 Cybersecurity validation, Automotive SPICE for Cybersecurity V1.0 SEC.4 Risk Treatment Validation。
表：ASPICE 4.0各过程与ISO 26262各章节对应关系参考
| 开发体系 | ISO 26262 | ASPICE | |
| 1 | 系统层面开发 | Part4 | SYS.1~5 |
| 2 | 硬件层面开发 | Part5 | HWE.1~4 |
| 3 | 软件层面开发 | Part6 | SWE.1~6 |
| 4 | 组织层面的管理 | Part2-5 | SUP.1 |
| 5 | 项目层面的管理 | Part2-6 | MAN.3/5/6 |
| 6 | 支持过程 | Part8 | SUP.8/10 ACQ.4 |
| 7 | 机器学习层面的开发 | N/A | MLE.1~4 SUP.11 |
那么如何建立一个流程既可以满足功能安全要求，也可以满足ASPICE相关的要求呢。总体上来说，首先建立符合软件开发团队的ASPICE流程，然后将ISO26262中相关要求融入到ASPICE中去，并对无法融入的流程进行额外的补充说明，实现ISO26262与ASPICE的融合。
具体来说，ASPICE和ISO26262同时都覆盖了系统层面的开发、软件层面的开发、项目管理及一些支持类过程。对某一个过程来说，如果有ASPICE要求，又有ISO26262要求，可以将要求进行合并。
活动的要求：ASPICE中BP/GP+ISO26262中的Requirements and Recommendations。
工作产品的要求：ASPICE中的Output Work Product + ISO26262中的Work Product。
11、写在最后
MUNIK秒尼科专业的ASPICE技术团队，由国内外的专业汽车安全研发和软件质量人员共同组成，我们提供ASPICE认证、ASPICE评估、SPICE咨询等技术服务，拥有专业的iNTACS认证的ASPICE评估师，通过导入ASPICE，能让您的研发团队在软件开发流程中的能力显著提升，欢迎联系MUNIK秒尼科进行合作，服务流程包含四个阶段：
最后，你是不是还为项目ASPICE实施发愁，请不要犹豫，关注上海秒尼科技术服务有限公司官网，获取更多服务内容~www.munik.com
标签：一文,软件开发,流程,ASPICE,MUNIK,过程,评估,4.0 From： https://blog.csdn.net/m0_61714886/article/details/140318685