# 汽车ECU开发达到ASPICE L1到底有多困难

背景介绍

最近大半年没有更新文章，主要有两方面的原因：

• 一方面是由于自己太懒，没有更新的动力；
• 一方面是为了让项目达到公司规定的ASPICE L1的标准，这半年来花费大量时间写各种文档；

这半年每个工作日都在写文档，周末时整个人都虚脱在床上，极不愿意盯着电脑屏幕。

目前，公司对于项目ASPICE的评审已经结束，坏消息是评审没通过，但好消息是暂时可以松口气修整一下。

今天有空写篇文章总结下这半年来为ASPICE评审所做的努力。

什么是ASPICE

ASPICE(Automotive Software Process Improvement and Capacity Determination)，汽车软件过程改进及能力评定，其是汽车行业用来评价ECU的软件开发团队的研发能力水平的框架。

随着汽车电子电气化的程度越来越高，ASPCIE标准逐渐得到OEM和零部件供应商的重视。比如，我司客户就硬性规定我司产品至少达到Level 1才能大规模装车。

另外，我司也将产品的ASPICE级别和研发经理、总监等诸多领导的KPI挂钩以引起领导们的重视。

ASPICE共分为6个级别，0为最低级，5为最高级。级别越高表明研发项目出现意外情况的可能性更低，企业对于项目和产品的开发的管理越规范，并同时具备向客户提供高质量产品的能力。

【0级】产品研发管理完全是混乱无序的状态

【1级】企业能够完成产品的开发工作，但缺乏管理，项目中无法掌控的因素过多，无法按时提供高质量的产品

【2级】企业能够按时完成产品研发工作，并在项目开始前指定完备的开发计划，并能根据计划管理项目进度，保证项目顺利进行

【3级】企业不仅能做好项目管理，而且通过历史项目积累经验和教训，并形成企业标准的开发流程和模板，并能够将其用于未来的项目管理。

【4级】引入统计学知识和技术，对项目相关各项数据进行统计和分析，并将之运用于未来的项目管理之中，达到对项目结果的预测，并根据预测结果对项目进行实时的调整，确保达成项目目标。

【5级】代表企业能够基于商业目标的需要，主动的对过程进行调整，对变革管理有很强的管理能力，能够基于对过程的量化分析设定明确有效的过程改进目标，并能对过程改进结果进行有效的量化监控和分析。

为了实现ASPICE L1，我做了什么

由于目前我只接触过ASPICE L1级别的项目，我主要说下今年为达到ASPICE L1级别做的那些事儿。

ASPICE主要是评估产品软件开发团队能力，主要就是审核各种开发文档。

由于汽车ECU遵循“V”开发模型，因此在V模型的每个开发阶段都需要有文档输出。

众所周知，软件开发包括：定义需求，软件开发，软件测试三部分。我司分的更加细致，但也基本属于这三大类，而我属于软件开发人员，所编写的均是软件开发的文档。

接下来，我主要介绍下软件开发阶段需要编写哪些文档才符合ASPICE的要求。

• 系统需求文档。该文档由我司系统工程师和OEM核对需求，并输出相应的系统需求文档

• 软件需求文档。该文档由我司软件开发工程师阅读系统需求文档，并与系统工程师沟通将系统需求进一步细化为软件需求，并输出对应的软件需求文档

• 软件整体设计文档。该文档由我司软件架构师将软件需求分配到不同模块，并定义各模块的功能和外部接口，同时也要确定软件的开发平台等硬件配置。同时，还要将设计各软件模块的公共需求提取出来，用于编写集成测试用例

• 软件详细设计文档。该文档由我司软件开发工程师编写，软件开发人员通过软件需求文档来定义各自模块的内部和外部接口。同时，软件开发人员还需要画出实现需求的流程图，并定义好相关函数的接口。

• 软件集成测试文档。该文档由我司软件开发工程师编写，软件开发人员根据整体设计文档中定义的需求，编写测试用例，并完成测试。

• 软件单元测试文档。该文档由我司软件开发工程师编写，软件开发人员根据软件详细设计文档中定义的每个函数编写相应的单元测试用例。

上述文档并非单纯的文档工作，而是彼此间有很紧密的联系。

• 软件需求文档要覆盖系统需求文档的所有需求；
• 软件需求文档中有些需求要整体设计文档覆盖，而有些需求要详细设计文档覆盖，这由软件开发人员筛选确定；
• 软件集成测试文档要覆盖整体设计文档中的需求；
• 软件详细设计文档要覆盖软件需求文档中的所有需求；
• 软件单元测试文档要覆盖详细设计文档中的每个函数

只有把上述文档全部完成，才算有资格参与ASPICE L1的评审。接着，评审人员根据自己的经验和标准要求审核这些文档，并提出自己的疑问。

如果评审人员完全不懂开发，那么恭喜你中奖，他们会问很多奇奇怪怪的问题。比如，评审人员曾问过我一个问题：你们软件中的各个task何时被调用，每个task的运行事件是多久，如果task运行未超时会怎样处理？

由于我从事嵌入式linux开发，我从未关心过task何时被调用，每个task运行多长时间。毕竟linux环境下运行的基本单位的进程，进程调度完全由内核处理。而评审人员还是按照传统MCU的思维进行ASPICE的评审。

对于这个问题，我解释了很久甚至差点进行现场测试，最后评审人员勉强接受了我的解释。

总结

为ASPICE L1忙活了大半年，虽说结果没达到预期，但在这个过程中学到了很多东西。

我相信ASPICE会在汽车行业中越来越重要，每个汽车行业的工程师都应该了解ASPICE是什么，如果能够有机会亲自参与其中，你一定也会对它了解的更加深刻，同时也能指导每个企业搭建和完善软件研发能力。

ps: 欢迎关注我的公众号[程序猿司晨]，分享汽车行业程序员成长过程汇总的烦恼和反思.