本文介绍汽车电子传统控制器应用层软件开发流程，为大家介绍各个流程环节的关键活动、产出物、所需的能力和工具以及一些相关经验等。

本文可以给想要从事汽车电子软件开发的人员提供学习路线，也可以给企业中入职的新员工作为培训材料。

汽车电子软件开发是一个系统性的规范化的流程，只掌握了C语言编码能力或者Simulink建模能力是不足以承担软件开发任务的，只有了解和具备了完整的开发流程的能力才可以。在求职时，我们可以通过“我掌握了软件开发流程的每一个环节的能力”来提高自己的竞争力。

传统控制器是指如车身控制器BCM、整车控制器VCU、电池管理系统BMS等，不包括智能驾驶和智能座舱的控制器。

本文主要从应用层软件开发的角度来介绍，底层软件开发人员也可以参考。

总览

软件开发流程相关内容总结如下：

说明：

1) 以上内容中，同时列出了手工编码和使用Simulink模型开发软件所需的工具，读者可以根据自己的情况进行选择，不是所有的工具都要掌握；

2) 部分工具是同一类型，选择其一或者选择你所在团队使用的工具即可，例如代码编辑和查看的工具VSCode / SourceInsight；

3) 如果是在工作前进行能力准备，部分工具的学习可以优先级放低，例如编译器、软件烧录工具，这些可以在工作中边用边学；

1.需求分析

需求是软件开发人员的重要输入，软件开发人员基于需求的具体要求进行软件逻辑的开发。需求分析是软件开发过程中至关重要的环节，但它难以被拆解为具体的能力点或依赖特定工具。

能否做好需求分析，取决于多个因素：

1. 需求本身的质量：包括需求的描述是否思路清晰、逻辑完备，这考验需求撰写者的能力；需求文档应当借助多种形式，例如图表、流程图等，而非仅通过文字描述需求。除了具体的软件需求，需求文档也应同时对需求相关的背景知识进行介绍，帮助阅读者更好的理解需求。需求编写时应使用需求编号，使得需求条目清晰，单个编号的需求颗粒度不应过大。

2. 软件开发人员的分析能力：包括能否正确理解和消化需求，能否基于需求文档梳理出清晰的实现思路和框架，以及能否识别需求中的潜在漏洞。

需求分析能力难以对应到具体的能力指标，可能与语文素养或文本阅读理解能力相关。但由于软件需求具有极强的逻辑性，开发人员的逻辑思维能力尤为重要。在需求分析过程中，可以借助表格、流程图、状态跳转图等多种工具辅助梳理需求。

需求分析工作不仅软件开发人员需要做，软件测试人员也需要。需求、软件、测试是软件开发流程中互相作用的三方，密不可分。

软件开发人员基于需求进行软件开发，测试人员基于需求的内容编写测试用例对软件进行测试，软件开发人员和测试人员在各自的工作过程中，发现需求的漏洞或者不合理之处，反过来帮助需求方完善需求，同样的，需求和开发也可以帮助测试人员完善和补充测试用例，形成一个不断迭代的闭环。

需求分析的过程中，经常会出现，一条需求不同的人的理解不同，大家都按照各自的理解去实施工作，因此需求评审非常重要。通过对需求的串讲与反串讲，来发现和澄清需求中的问题，减少理解不一致导致的潜在问题。

需求串讲：需求撰写者向软件开发和测试人员讲解需求；

需求反串讲：开发人员和测试人员根据自己的理解，向需求撰写方“反向”讲一遍。

需求和软件类似，也是一个可能有bug的交付物。我们不能要求需求方一次性把需求写完整和正确，就像我们不能要求软件开发人员开发出没有bug的软件一样。需求和软件一样，也是需要通过“评审、实施、测试、修复”这个过程不断迭代和完善的。测试人员不仅负责发现软件的bug，也应负责发现需求的bug。

需求的提供形式可能多种多样，可以直接以word文档的形式提供，也可以使用DOORS这种专业的需求管理工具。需求应做好版本管理，软件开发人员在发布软件时，应明确对应的需求版本，以避免软件与需求不一致，导致不必要的bug。开发人员在进行软件开发时，应做好软件与需求的对应和追溯关系，以避免需求遗漏。这也是ASPICE、功能安全等流程对软件质量的基本要求。

如下是一些需求样例：

开发人员在进行需求分析的过程中，通常也在同步进行软件架构要素的梳理和设计，需求分析和架构设计工作通常是耦合在一起的。

能力或工具：

分析和总结能力、逻辑思维能力、语言表达能力。

Doors、Excel等。

产出物：

需求分析过程中可以同步输出一些总结性文档，对功能的接口信息、时序、逻辑等进行总结，形式不一，流程图、状态机图、时序图、表格、文字等都可以。这部分内容也可以与下一节的架构设计中的软件架构设计说明书等文档进行整合。

2. 架构设计

架构设计是指根据需求设计软件实现的模块。简单的需求可以用一个软件模块实现，复杂或体量大的需求，可能需要多个软件模块实现，模块之间的接口、数据流、功能划分、逻辑配合等设计是否合理，就考验开发人员的架构设计能力。

架构设计能力与前面的需求分析能力类似，无法拆解成具体的能力点，或者总结出固定通用的方法，我觉得比较考验开发人员的经验和能力。虽然如此，我们还是可以总结出一些共性的架构设计要素和方法的。

当我们在对一份需求进行分析的时候，就可以同步梳理出如下信息：

接口相关的信息

1) 该功能模块的接口有哪些（包含输入、输出）？

2) 接口的数据源或者接收方是哪里（是另一个软件模块，还是总线数据，还是硬件接口）？

3) 接口数据的更新机制是什么样的？（是周期性更新的CAN总线数据，还是事件触发式的更新机制）？

这些信息都会影响到软件逻辑的设计细节。是我们在分析需求和设计软件架构时必须要梳理的内容。

调度机制的确定 

我们在实现应用层模块时，大部分情况都是设计一个或多个周期调用的函数来实现。那么调度周期的大小如何确定呢？这一般从需求对于功能的响应速度的要求来进行分析。

比如要求从用户点击中控面板上的“打开双闪”按钮，到左右转向灯开始闪烁，时间在500ms以内。那么开发人员要分析整个链路，除去上游的按键状态检测和数据传输，下游的控制信号发送和转向灯响应时间，留给本模块的时间剩余多少，这决定了当前模块的函数周期大小。函数周期太大，响应太慢，不满足功能响应时间的要求。函数周期太小，浪费芯片的计算资源，徒增软件运行负载。

也有一些场景需要设计非周期性调用的函数，需要根据功能的具体要求来分析和确定。

以上信息是从需求层面可以直接梳理出来的。如果需求量大，我们计划用多个模块来实现，那么这些细分的模块，如何分配功能就很重要，它们的功能分配，决定了它们之间的接口、数据流等信息。一般来说，要求模块设计高内聚、低耦合，数据流关系尽量简单，不要有太复杂的交互逻辑。这部分的内容，与具体的需求内容强相关，不太好总结出通用的普适的可直接应用的方法。

架构设计常用的工具

当前AUTOSAR架构在汽车电子软件行业被广泛使用，Vector 公司开发的Davinci Developer软件就是用于设计符合AUTOSAR规范的应用层软件架构的工具。

感兴趣的朋友可以在B站查看我的AUTOSAR SWC设计教程：

AUTOSAR SWC 设计教程 01 快速入门 - 基于一个最小案例_哔哩哔哩_bilibili

Matlab软件提供的System Composer工具箱也可以用于软件架构设计，通过定义和映射AUTOSAR元素，也可以产出符合AUTOSAR规范的模块架构描述文件arxml文件。

如果我们不需要遵从AUTOSAR规范，那么使用excel、visio、word等文档，也可以进行模块架构设计的具体内容的描述和记录。

以上提到的工具只是帮助我们将架构设计形式化、文档化，会用这些工具不代表就能做出好的架构设计。

产出物

模块的架构描述文件

例如arxml文件，AUTOSAR规范下的arxml文件描述了模块的接口、调度机制等重要和基础信息，可使用Davinci Developer或Matlab System Composer软件输出；

如果你不使用autosar架构，也可以用其他工具来承载模块的架构描述，比如word、visio、excel等，无固定形式，能把架构信息描述清楚即可。

软件架构设计说明书

虽然有上面的模块的arxml文件，但是一份软件架构设计说明书还是必要的。软件架构设计说明书描述实现该功能的各个模块的功能划分、接口设计、交互逻辑、时序关系等，从整体上对软件架构设计进行介绍，方便开发人员了解功能的具体实现。这些文档在功能负责人发生变更，进行工作内容交接时非常有用。

3. 软件开发

完成软件架构设计后，就可以进行软件开发了。在汽车电子传统控制器的软件开发中，主要是使用C语言或者Simulink进行软件开发，Simulink一般用于应用层软件开发。无论是使用C还是Simulink开发，C语言都是一项必备的基础技能，应当熟练掌握。对于C语言需要掌握的深度，我认为计算机二级考试所要求的知识点就够用了。针对具体需求使用C或者Simulink进行开发时的所依赖的能力和经验，需要在实际工作中去学习、积累和总结。

使用Simulink开发软件完成模型设计后，还需要进行代码生成，将模型转化成代码。

需求和软件的追溯

根据ASPICE和功能安全等相关的要求，需求和软件应当能够进行双向追溯，从而保证需求没有遗漏。需求和软件的追溯关系建立的方式，可以人工手动在代码或者模型中添加需求编号，也可以使用一些文档来记录。需求管理工具也能建立追溯关系，例如DOORS和Matlab的Simulink Requirments工具箱。

除了需求和软件需要进行双向追溯，下游的测试人员编写的测试用例，也要求与需求建立追溯关系，确保每条需求都有测试用例覆盖，没有被漏测的需求。

软件版本管理

软件的版本管理非常重要。我们可能同时在维护一个或多个项目，软件版本在不停的迭代。每次软件版本迭代时的变更内容需要明确记录，有时候需要去查看过去的某个版本，或者回退到过去的某个版本进行发布，这些情况都很常见。软件版本的管理工具有GIT或者SVN等，开发人员应当掌握其基本用法。

代码编辑器

在软件开发过程中，还需要使用到的一些工具有：

代码查看和编辑工具：vscode / source insight / notepad++ / visual studio

即使是使用Simulink进行开发，代码查看和编辑工具也是必须的，我们经常需要在完整的项目工程代码中进行代码查看、问题分析等。因此开发人员必须至少要掌握一种代码查看和编辑的工具。

notepad++可以方便快速的用于查看单个代码文件或者其他的文本文件。notepad++的搜索功能中的“在当前文件中显示所有搜索结果”一直是经常被使用到的。

代码比较工具

在软件开发的日常工作中，代码比较工具是贯穿开发、迭代与排查全流程的刚需。在代码开发和迭代场景，开发者通过对比本地代码与远端分支的差异，可在提交前进行自审，避免误改他人逻辑或提交了错误的代码；在问题排查场景，通过对比正常版本与故障版本的代码或配置文件，能帮助快速查找导致Bug的变更内容，避免在大量无关代码中盲目猜测。

以Beyond Compare为例，它支持文件夹快照对比和三向合并，可以直观地高亮显示哪些文件是新增、删除或修改的，并深入代码行级排除仅由注释或空格引起的无意义差异。我们使用GIT提交merge request时，git系统也会自动将代码差异呈现出来，供开发人员检查。

产出物

软件

模型及模型生成的代码（包括相关的数据文件，如m文件、mat文件、sldd文件等）

或 手工编写的代码

配置工具生成的代码（例如davinci configurator生成的代码）

软件设计说明书

软件设计说明书，是针对某一个软件模块的设计思路进行介绍，帮助其他人快速了解这个模块的设计逻辑。

软件发布说明书 release notes

软件发布说明书用于清楚的写出当前交付的软件版本与上一版本的变化，比如新增了什么功能、删除了什么功能、修复了什么问题、有哪些未解决的问题、有哪些未实现的功能等，这些信息非常重要，是下游测试人员的输入，测试人员需要根据功能变更进行测试。也是做好版本管理的重要输入，后续如果需要进行版本回滚，这些版本的变更说明就非常重要。

软件发布说明书，与前面我们提到的使用git等工具进行的版本管理，有重复之处。我们在git上提交代码合入请求时，也被要求进行变更描述，一定程度上可以取代软件版本说明书。是否要提供软件发布说明书，要看每个公司的具体要求。

4. 软件验证和测试

软件评审

模型评审或者代码评审，或者叫做同行评审，通过其他同事的评审，找出软件设计中的问题。这些经验可能来自于开发过程中形成的一些设计共识，或者一些常见的错误设计，也可以把这些经验固化成设计参考文档，供开发人员参考。

除了上面提到的通用的软件设计的评审，还有就是针对当前开发的功能，进行架构设计和软件设计的评审。这需要对功能需求有一定的了解。一般来说负责开发该模块的人员是最熟悉这个模块的软件需求的。其他参与评审的同事如果不是负责该模块，则对软件需求无法有比较全面和细致的了解，他们也没有时间去做全面和细致的了解，因此在针对该功能的具体的软件设计上，并不一定能提供太多的意见。

根据我的经验，我认为针对一个功能，最好形成一个 1 + 1 的模式，就是1个员工负责该功能的软件开发，是该功能的主要负责人。另一个员工也要对这个功能的需求和设计有足够全面细致的了解，主要作为评审的角色，这个角色可以是软件经理。这样在软件开发、软件评审、后续的问题排查阶段，这个1 + 1模式都可以形成协作，避免一个人孤军奋战，无法与同事沟通讨论。而在主责同事有事无法及时进行软件并更开发和问题排查时，另一个同事也可以及时顶上。

软件评审工作可以输出一个评审报告或记录，以满足一些流程要求（ASPICE、功能安全等）。

Simulink 模型设计规范检查

如果是使用Simulink开发软件，非常建议在完成模型设计后，先使用Simulink提供的Model Advisor进行检查，以确保模型符合建模规范、行业标准，也可以帮助找出其中的一些设计错误。

使用Model Advisor时，不必要求规范中的每一条都要严格符合。团队可以在例如MAB规范中选择出认为必要的规则进行检查。对于确实无法符合的情况，做出解释即可，不必强制要求一定要符合，不可形成死板的规定。过于全面和严格的规范检查要求，会给开发人员造成负担，产生相反的效果。

代码测试

手工编码开发的软件，可以使用例如Tessy、VectorCast这种测试工具进行测试。

代码测试中针对单个函数进行的测试，即单元测试。我们也应当将功能逻辑上相关的函数放在一起，构建和模拟它们的调度关系来进行测试，即集成测试。集成测试可以验证函数之间的交互逻辑、接口和架构设计等是否符合设计初衷。

模型测试

使用Simulink开发的软件，可以使用Simulink Test工具箱进行模型测试，也可以叫做MIL测试。相比于代码测试，模型测试还要做一个测试环节，就是SIL测试，或者叫背靠背测试，这是为了验证模型和代码的一致性，也是使用Simulink Test工具箱进行的。

我们可以认为针对一个模型的测试是单元测试，但实际上一个模型通常生成不止一个函数。我们也应当将功能逻辑上相关的模型放在一起，构建一个集成测试的环境，来验证模型之间的接口、配合等情况。我们可以在一个空模型中，使用模型引用模块来搭建这个集成测试的环境。

软件开发的自测，有覆盖度的要求。例如语句覆盖、分支/判定覆盖率、条件覆盖率、MC/DC覆盖率等。具体要满足哪些覆盖率，要达到多少覆盖率，根据团队的要求决定。完成测试后，应提供测试报告。

静态代码分析

静态代码分析是一种在不实际执行程序代码的情况下，对源代码进行自动化扫描和检查的技术。它能够在软件运行前深入剖析代码的内部结构和逻辑，提前发现潜在的问题。例如代码质量与逻辑缺陷（如未初始化变量、死代码）、规范合规性（例如是否符合MISRA C规范）等。静态代码分析工作也会产出一个静态代码分析报告。

常用的静态代码分析工具有：QAC、Polyspace等。

在软件编译的过程中，编译器一般也会对代码进行检查，并提示一些错误或告警信息，开发人员应当也关注这部分内容并进行处理。

5. 软件集成

完成上述代码开发和验证测试的工作后，下一步是要将自己功能模块的代码与整个工程中的代码进行集成编译。一般来说，集成工程师负责整个工程的维护，软件开发人员只需要将自己模块的代码放到工程中指定的目录，使用编译器进行编译即可。如果是使用AUTOSAR架构，则在此之前，应完成AUTOSAR架构层相关的代码的生成和集成（例如使用Davinci Configurator生成各模块的代码，并放到工程中的指定目录）。

进行代码集成时，还要确认模块相关的代码是否到位。例如上面提到的AUTOSAR架构层的代码是否到位、和本模块对接的上下游的模块的代码是否到位，有些相关代码没有到位，可能导致工程编译报错。

如果编译器编译代码报错，开发人员应具备分析和解决报错的能力。根据编译器的报错信息，去排查原因并解决。报错原因也可能不是本模块代码的问题，也可能是和其他模块的配合问题，这时候就需要去和其他同事沟通解决。集成代码解决报错的能力，和前面提到的架构设计、软件开发类似，是一个不断练习和积累经验的过程。

集成工作中可能用到的编译器有Green Hills、HighTec、Tasking等，根据项目的具体情况而定。

作为软件开发人员，编译器工具不用专门去学习使用方法，跟随集成人员学会如何添加代码和编译即可。

6. 台架测试

本节介绍的台架测试是指开发人员自己搭建和使用的测试台架，不是专门的测试团队的测试台架。开发人员完成软件测试后，也非常有必要搭建一个包含ECU控制板的测试台架，对功能进行系统的测试。

一个最简单的测试台架应该包含：

1) 控制器ECU：即被测对象，比如车身控制器BCM

2) 线束：根据ECU针脚定义定制的连接线缆。它替代了实车线束，用于连接ECU、电源、总线分析仪等所有设备，是台架的“神经系统”

3) 电源：提供ECU所需工作电压（如12V/24V）

4) 总线分析工具：连接电脑与ECU的硬件，发送/接收CAN/LIN/Eth等总线信号，并通过软件监控、记录、仿真数据，例如Vector公司的CANoe。

5) 信号模拟工具：由于ECU需连接传感器（如温度、压力）和执行器（如电机、灯泡），在台架上需模拟其电气特性，模拟传感器信号（电阻、电压、PWM等），根据ECU的功能确定具体要模拟的内容。

6) 电脑：采集总线相关数据，对功能进行测试分析。

如下图，开发人员应当能够理解和搭建这个最简单的测试台架。

如果是一些功能更复杂的控制器，例如电池管理系统BMS，涉及到高压信号的采集，或者是一些需要复杂的硬件资源接口的控制器，可能要用到更专业的测试设备。例如dSPACE公司的SCALEXIO测试台架，也可以称之为HIL测试台架。这样的台架需要去了解机柜的使用方法和配套的软件的使用方法，有一定工作量，一般由专门的测试团队去维护。

如果将被控对象也集成到一起，可以形成一个更完整的台架，如下是一个包含座椅的座椅控制器测试台架示例。这样的测试环境一般由专门的测试团队维护。

在搭建好功能完备的测试台架后，开发人员需要将编译好的软件烧录到芯片中，这个过程会使用到刷写工具，例如针对NXP芯片的S32 Flash Tool、Lauterbach TRACE32、J-Link等。也可以使用CAN工具基于UDS协议刷写软件，

软件烧录后，就是在台架上对软件功能进行测试。这个过程可能包含的动作有：

1) 使用总线分析工具模拟发送报文、接收报文数据并分析等；

2) 对ECU的硬件接口的输出状态进行检查，例如使用万用表测量GPIO的电平、使用示波器测量PWM信号的占空比等；

3) 软件调试，针对问题进行调试分析，使用调试工具例如Lauterbach TRACE32、J-Link进行断点调试、查看变量数值等；

开发人员的台架测试一般不要求测试覆盖度达到100%，主要是对主要的功能逻辑和场景进行测试，保证基本功能场景可以正常运行。更细节和全面的覆盖度测试可以在前面的软件验证和测试环节进行。

不同于前面介绍的代码测试或模型测试（只是单个函数或单个模型的单元测试，或多个函数或多个模型的集成测试），台架测试是对完整的软件+硬件的ECU板子进行测试，软件也包括应用层软件和底层软件等，因此是一个更完备的测试。其测试结果正确才能保证软件的功能在ECU板子这个环境中是运行正常的（依然不能保证在实车上是正常的，还可能出现多个控制器之间配合的问题）。

台架测试环节可以输出一份测试报告，可称之为功能测试报告或集成测试报告。

7. 软件发布

软件发布是指完成前面所述的工作后（功能开发测试完毕，自测功能正常），开发人员就可以将自己的软件进行发布，供集成工程师集成后，制作正式的软件，发布给测试团队进行测试，后续就会升级到车上进行使用。

软件发布的具体动作是指：

1) 提交代码到集成工程侧，例如在Git上提交Merge Request，提交时应写清楚变更内容和背景，以便后续回溯查找；

2) 提供本次功能变更相关的文档，例如软件发布说明书、测试报告等；

这些动作的具体内容在前面的章节已有介绍。

8. 问题分析和修复

问题分析是开发人员工作中工作量相当大的内容。产生问题的环节可能在：

●开发人员自测

●软件发布后测试团队测试出的问题

●软件上车后在实车上测试出的问题

●车辆交付到客户手中后出现的售后问题

出现问题后，开发人员应当首先对问题边界进行界定。一般提出问题方应当提供问题发生时的各类测试数据，开发人员根据功能逻辑对数据进行分析，界定问题的责任方。因为一个功能可能是由多个模块实现的，我们要界定出该问题是否是本模块产生的。

分析问题的过程中，应当和测试人员、需求方等相关人员进行充分沟通，了解相关信息，共同讨论分析问题原因。

分析问题时，可以尝试在测试台架上进行复现。根据测试人员提供的问题出现场景的操作方法，尝试进行复现。如果能在测试台架上复现问题，是非常有利于问题分析的。此时我们可以使用各类测试工具、调试工具对问题原因进行排查。根据问题情况的不同，这部分工作可能涉及很大的工作量，且非常依赖经验、逻辑分析能力及其他各类综合能力，例如对调试工具和测试工具的掌握能力等。

如果是使用Simulink开发的模型软件，我们也可以在Simulink的环境中尝试复现问题，如果复现，就可以在模型环境中直接进行问题分析定位。

出现问题时，也可能需要开发人员去其他测试环境进行让问题分析，例如测试方的测试台架、实车。开发人员应当了解基本的实车环境，例如总线数据采集的方法（接口在哪里、线束如何连接）、诊断功能的使用、12V小电池的供电接口操作（开发阶段经常切断、接通12V供电），甚至包括开车。

定位出问题原因后，开发人员就要对软件问题进行修复，这个过程可能包含：

1) 确认修改方案并修改软件；

2) 对问题修改方案和软件变更进行评审；

3) 完成软件测试、台架测试，并输出测试报告；

4) 发布软件；

也就是说要将前面介绍的各个环节重新走一遍（架构设计环节也可能会涉及，例如增加了接口）。

缺陷跟踪系统

针对问题一般有专门的缺陷跟踪系统对问题进行记录、处理、跟踪等，开发人员需要在问题流转到自己时进行处理，例如填写问题发生原因、修改方案、修复时间和版本等。例如JIRA系统。

问题分析过程中涉及到的能力和工具，在前面的环节基本都涉及了，例如总线分析工具的使用如CANoe、调试工具的使用如Lauterbach TRACE32，其他例如使用matlab或python编写一些脚本工具辅助问题分析等。根据具体的控制器和功能而定。

9. 其他相关能力

其他一些不与特定功能绑定的、通用的知识或能力包括：

1) 车载通信协议，如CAN、LIN；

2) UDS诊断协议的理解和使用；

3) ASPICE流程中关于软件开发的部分；

4) 功能安全相关概念；

5) AUTOSAR架构；

这些内容也是汽车电子软件开发中必备内容，在工作中的各个环节都可能经常涉及相关内容，开发人员应当具备这些内容的基础知识。

以上流程内容，是基于作者在汽车电子传统控制器应用层软件开发的工作中的经验进行的总结，不保证完全全面和正确，供大家参考，欢迎各位同行指正和补充。

10. 相关课程

快乐的宇航boy和合作的朋友们提供了如下课程，可以帮助大家掌握软件开发流程的相关环节的能力：

欢迎大家在我的B站查看相关课程内容

可以在B站小店和我的淘宝店铺下单付费课程，淘宝店铺有课程内容的详细介绍。

淘宝店铺名：快乐的宇航boy

建议添加我的微信，了解课程情况

微信号：happyyuhangboy