来源 | 造型 STE，汽车技术研究
如今的汽车越来越智能化，无人驾驶也并非遥不可及。 届时，人们只需要坐在车上喝茶就可以到达目的地。 然而，智能汽车内部有密集的电路和无处不在的电子元件在工作，人们无法察觉。 这就是汽车的“大脑”——电子控制系统。 正是这种日益复杂的电子控制系统，辅助甚至取代了驾驶员，监控和控制车辆的运行状态，让人们的出行变得更加轻松、简单、安全。
1、汽车电子控制系统的发展历程——从简单到复杂
回顾七十年前的汽车，只有起动机、电池、车灯等少数电子器件，四十多根电线就可以满足整车电子部件的需要。 20世纪80年代，随着IT技术的发展，汽车工业掀起了电子电气化的浪潮，各种安全配置也随之诞生。 配备软件系统的电子控制器开始在汽车中扎根。 随着控制器数量逐渐增多，不同控制器之间需要解决通信问题，CAN总线和LIN总线应运而生。 2007年，奥迪Q7、保时捷卡宴线束总长度超过6公里。 线束长度的增加和控制器数量的增加给车企带来了巨大的成本压力。 随后，汽车电子控制系统开始向集中化方向发展。 目前特斯拉Model S和Model 3的线束长度约为3公里和1.5公里。
汽车主要系统的软件功能逐年快速增长。
线束长度的变化体现了汽车电子控制系统从简单到复杂的巨大变化。 作为电控系统的重要组成部分软件开发的过程，软件开发变得越来越复杂。
2、汽车电控系统基础部件——传感器、ECU、执行器
1.电子控制单元（ECU，包括软件）。 ECU是汽车电子控制系统的大脑。 它对各个传感器输入的电信号和某些执行器反馈的电信号进行综合分析和处理，为传感器提供参考电压，然后向执行器发送控制信号，使执行器按照控制目标进行工作。
软件系统集成并存储在电控单元内，其核心是微处理器。 这种微处理器通常采用单片机，功能扩展方便，控制精度较高。 完成数据采集、计算处理、输出控制、系统监控和自诊断等。
2、传感器是汽车电控系统的信息采集器，类似于人的眼睛和耳朵……它将汽车的各种物理参数转换成电信号，传输给电控单元。
3、执行器是汽车电控系统的执行器，类似于人的手和脚。 电子控制单元通过执行机构对被控对象进行控制。 执行机构对电控单元输出的控制信号快速响应，使被控对象在设定状态下工作。
3、汽车电子控制系统的基本工作原理
汽车电子控制系统在ECU中预先存储了一系列指令程序。 这些指令程序在设计和制造过程中已经确定，正在等待来自各种传感器的输入信号。 工作时，ECU将接收到的传感器信息与内存中的“标准参数”进行比较软件开发的过程，然后根据结果控制执行器采取相应的动作。
4、汽车软件系统开发流程
随着智能互联、自动驾驶、电动汽车和共享出行的发展，软件、计算能力和先进传感器正在逐渐取代发动机的主导地位。 与此同时，这些电子系统的复杂性正在增加。 以当今汽车中包含的软件代码行数 (SLOC) 为例。 2010年主流机型SLOC在1000万线左右； 到2016年，已达到约1.5亿行。 复杂性如滚雪球般增加，不可避免地导致与软件相关的严重质量问题：我们在最近的几次大规模车辆召回中已经看到了这一点。 据ADAC（全德汽车俱乐部，德国最大的交通协会）统计，2004年德国40%的车辆故障最终归因于软件问题或电子元件故障。 为此，必须在保证电子系统整体可控性的同时开发新功能。 于是就出现了一个先拆解、再开发、再整合的过程。
首先，将电子系统研发拆解为软件系统、硬件系统、传感器和执行器四个部分。 V模型流程开发完成后，最后再次集成。 这个V模型涵盖了从系统级到软件级的流程以及集成后的功能测试和系统测试。 这是当今汽车行业广泛使用的开发过程。
软件开发流程：
1.分析最终客户需求并定义逻辑系统架构
这一步是根据最终客户的需求和法规要求定义车辆软件系统的逻辑架构。 包括各主要功能块的定义、功能块接口定义以及功能块之间的通信定义。 该步骤仅考虑满足原有需求，不涉及技术层面的具体分析。
2.分析逻辑系统架构需求并定义技术系统架构
逻辑系统架构为定义具体技术层面的系统架构提供了基础。 在这一步中，我们开始讨论具体的技术问题，哪些功能将通过软件来实现，软件块封装在哪些电控单元中，电控单元之间采用什么通信协议等。软件系统开始成形。
3. 分析软件需求并定义软件架构
这里我们开始分析电控单元中软件本身的要求。 根据需求定义适当的软件架构。 同时，还必须考虑电控单元存储资源的优化利用、满足安全法规的冗余系统设计等。 在这里，软件将进一步细分为更小的软件组件，并定义每个组件之间的接口、层和边界。
4. 定义软件组件
继续为每个软件组件定义需求。 这里的需求集中在功能层面，具体的软件实现方法尚未考虑。
5. 设计、实现和测试软件组件
根据具体需求，工程师开始分别构建不同的软件组件。 经过前面一系列的拆解、分析和定义，我们终于到达了软件最核心、最具体的世界——代码。 这和知名程序员直接写代码略有不同。 传统的汽车软件开发采用基于模型的开发。 如下图所示，逻辑运算通过模型来表达，比代码更直观，方便以后的标定工作和维护。 在电子控制单元中，有数千个这样的功能。 下图所示的功能模型组合在一起，就会形成一个数万页的文档。 该文件是后续所有流程的基础。
当然，这套模型只是一种方便工程师之间交流的高级语言。 最终，它们会被人类或计算机转换成代码，输入到控制器中进行工作。 早些年，模型到代码的转换工作都是手工完成的。 这样带来的问题是代码无法统一和标准化。 面对一个软件逻辑模型，程序员可以使用多种方法来完成代码编译，以达到相同的功能效果。 然而，硬件资源或代码运行的严格程度可能会有很大差异。 因此，转码工作近年来逐渐被机器取代。 软件工程师提前定义标准编译规范，保证最终代码的统一和规范。
每个软件组件完成后，必须进行相应的软件测试。 本文不会关注功能级别测试，仅关注软件本身。 例如，软件是否因设计不当而出现死循环、各信号定义的范围是否合适、是否会引起溢出错误、是否会有除零运算等。这些，工程师必须提前定义测试计划，由计算机进行全方位的软件逻辑测试。 例如，if 和 else 语句需要测试每种可能的情况。
6. 集成和测试软件组件
单个软件组件的开发和测试完成后，它们被集成在一起，在每个电子控制单元中形成完整的软件包。 这个软件包集成后还需要进行测试，检查组件是否兼容、是否有开放接口等。
7. 系统集成与测试
当软件包的集成测试完成后，它们将被闪存到每个电子控制器中。 每个控制器通过线束与相应的传感器、执行器等连接，最终在控制器之间建立总线通信。 就这样，整个电子系统终于诞生了。 就像一个新生儿一样，这个系统仍然非常脆弱和不成熟，而且仍然有巨大的潜力等待开发。
系统集成后的首次测试常常充满问题。 由于系统高度复杂，每个研发组件都是单独开发的。 即使之前有严格的测试流程，仍然会有很多bug被漏掉。 如果开发过程中参与研发的各个部门之间沟通不足，整合后可能会出现各种兼容性问题。 对于每一个问题，工程师都不会忘记上面提到的拆解和控制。 消除表面问题，找到根本原因，修复软件错误，并掌控整个系统。
8. 校准
系统测试完成后，将进入软件校准阶段，这也是软件开发的重要阶段。 在软件实现阶段，工程师会在软件中保留一些可校准的参数，而不是固定值，等待校准。 这是基于成本考虑。 车型种类繁多的整车厂无法为每个车型开发单独的软件系统。 通用的解决方案是开发适合多种模型的平台软件。 然而，每个模型都有自己的特点。 平台软件无法让这些特性发挥作用，但校准可以。 通过改变不同的参数值，车辆可以实现不同的行驶性能，这也给标定工程师很大的发挥空间。
9. 系统测试和验收测试
标定完成后，进入整个流程的最后阶段。 基于流程开始时提出的需求，忽略具体的技术实现方法，从整个系统的角度审视是否满足最终客户的需求。 至此，整个软件系统已经非常成熟。 在正式进入量产之前，所有软件和校准变更将从某个时间点开始停止，为最终量产做准备。
当你走下整套V模型时，可以看到左右每个环节都是一一对应的。 需求为定义测试计划提供了基础，测试结果将推动进一步的开发和改进。
你可能会问，如果你从V模型的左上角一直走到右上角，最后一步测试发现第一步的系统架构存在设计问题，是不是是不是太晚了？ 我们必须重新开始一切吗？ 事实上，软件系统非常复杂，需要较长的开发周期。 如果你只是沿着V模型从左到右慢慢走，等到最后一步才发现问题，那就太晚了。 因此，在实际研发中，会出现持续集成、持续测试，工程师会多次从左到右重复V模型。
在研发初期，还没有原型车时，软件测试将依靠车辆仿真系统在计算机中进行。 发动机、变速箱、电子控制器、总线等都虚拟地存在于工程师的计算机中（SiL，软件在环）。 。 在仿真系统中，汽车可以像真实一样驾驶，模拟各种工况供工程师测试。
随着车辆模型的发展，一些电子控制器被开发出来，它们可以替换那些虚拟电子控制器进入测试环境，但其他组件仍然是虚拟仿真（HiL，硬件在环）。 直到有一天，样车开发完成，软件集成和测试进入测试台。 最后，样车调试并上地，软件测试进入实车阶段。 可以说，软件开发的起点很早，从虚拟到现实，一直持续到量产的最后前夜。 事实上，目的只有一个。 通过不断的集成和测试，我们可以尽可能地发现所有的问题，保证汽车的驾驶性、舒适性和安全性。
5、汽车电子软件发展趋势
1.ECU集成度将提高
早在去年，大众汽车就宣布力争汽车内只配备一个ECU。 一些供应商巨头内部确实存在这种情况。 尤其是在ADAS和自动驾驶下，集成的ECU架构显得尤为重要。
