IATF 16949：2016中对嵌入式软件提出了明确要求，提供嵌入式软件的供应商必须基于Automotive SPICE（或同等标准）进行软件开发以保证软件质量，并提供基于Automotive SPICE（或同等标准）的评估报告。 

ASPICE在目前汽车行业存在的背景及意义，主要从这四点可以体现，第一点是新版16949在产品开发过程中，以及附录的参考软件开发模型中都提出了对汽车嵌入式软件开发的质量要求，第二点是合资主机厂以及本土主机厂也分别响应了16949的要求对供应商和合作伙伴提出了嵌入式软件开发的质量要求，并且在项目过程中进行相关要求的审核，第三点，越来越多的电子电控产品被要求实施ISO26262功能安全，ASPICE作为嵌入式软件开发的流程要求，是实现功能安全要求的基础，第四点也是最贴近实战的，同样也是ASPICE在审核过程中最关注的要求，便是过程的追溯性，从而保证了在满足客户的基础上保证了产品的质量。

从刚刚的介绍中也不难看出，我们主要关注的重点就是汽车电子电控产品中嵌入式软件的质量，随着新能源汽车的快速发展，以及人工智能的日益发展，电子电控产品将会在整车中扮演着越来越重要的角色，诸如ADAS，BMS等零部件将会承载着之后整车上的主要功能，16949也分别在各项开发阶段以及售后阶段的条款中提出了具体的要求，并且目前越来越多的汽车召回也是由此类零部件引起的，因此嵌入式软件作为该类零部件功能实现的主要角色，它的质量将会至关重要。

就16949标准中提到了两个参考模型分别是APICE和CMMI, 两个模型之间的区别可以从过程域范围，认证方式，主要客户三方面来归纳。

ASPICE初期是由德国几大著名主机厂形成联盟后对零部件供应商提出的一个嵌入式软件开发的要求，模型本身从两个维度对嵌入式软件开发流程提出了建议要求，在该模型中对每个过程域提供了最佳实践，通过对这些最佳实践的理解，可以形成适用于自己组织的流程，另一个则是对流程定义完成后在具体项目中实施情况的一个评价体系，在这两个维度的基础上进行审核，从而评估出开发水平是符合模型中的哪一级别的能力水平。模型对过程域有自己的类型划分，但我在这边根据历来的项目经验及公司通常的组织架构重新进行了分类，可分为右边三角形中提到的四块，分别是项目管理，质量保证，支持管理及最重要的的V-Model开发过程。

刚刚在最开始的时候介绍了 ASPICE作为ISO26262实施的基础，这边显示了我个人理解的功能安全要求贯穿于整个电子电控产品开发的全过程，从系统，硬件，软件及机械四个方面的传递和过程。之后的分享会更加具体的介绍整个过程的传递要求及追溯要求。

无论是否需要获取认证（当然希望大家通过对ASPICE的深刻理解进行过程改进从而来获取认证），导入和实施ASPICE的项目过程还是分为四个阶段，

第一阶段为差距分析，

第二阶段为过程定义，

第三阶段是应用实施，

第四阶段进入到预评估及最终评估，

基本的四个阶段通常需要组织投入人力和工时通过1年半的时间努力来达到目标，当然最为关键的愿景及需求是来自于管理层的支持和肯定。

通常一个项目需要图中的这些角色来承担相应的开发工作，那么对于ASPICE的能力建设通常组织的做法是由这些工程师兼职来完成，因为在组织中数他们对业务流程最清楚，这也就是为什么在之前的介绍中，我将过程域分成了4个板块来介绍，另外需要强调的一点是质量保证的独立性，这一点在任何一个流程中都是非常重要的，当然高层的支持以及利益相关者的要求仍然是第一要点。

目前有些审核老师或者咨询机构非常强调工具的重要性，当然我同样认为在现今迭代要求高，且功能越来越复杂的情况下，工具是非常重要的一点，在整个开发过程中实际上涉及到相当多的工具，我在这边也不一一提及相关工具的名称，我强调一下这些工具所要实现的原则，以及对ASPICE实现的重要意义。