汽车电子控制系统中的软件开发过程

如今的汽车越来越智能化，无人驾驶亦非遥不可及，届时人们只需要坐在车里休闲喝茶即可到达目的地。然而，在智能汽车的内部却是人们察觉不到的密密麻麻的线路以及无处不在的电子起件在工作，这就是汽车的“大脑”——电子控制系统。正是这套越来越复杂的电子控制系统完成辅助甚至替换驾驶员的动作，实现对车辆运行状态的监测与控制，使人们的出行更轻松、简单、安全。

一、汽车电子控制系统发展过程——由简及繁

回想七十年前的汽车，电子设备仅有起动机、电池、车灯等为数不多的几个，四十几根导线就可以满足整车的电子部件需求。上世纪八十年代，随着IT技术的发展，汽车业掀起一场电子电气化浪潮，各种安全配置随之诞生。搭载软件系统的电子控制器开始在汽车上生根发芽。随着控制器数量逐渐增多，不同控制器之间需要解决通信问题，CAN总线、LIN总线应运而生。2007年奥迪Q7和保时捷卡宴的线束总长度突破6km,不断增加的线束长度以及越来越多的控制器给车企带来巨大的成本压力，随后汽车电子控制系统开始向集中化发展。目前特斯拉Model S以及Model 3线束长度大约3km和1.5km。

汽车各大系统的软件功能逐年快速增长

线束长度的变化从侧面反映出汽车电子控制系统由简及繁的巨大变化，软件作为电子控制系统的重要组成部分，发展更趋于复杂化。

二、汽车电子控制系统基本组成——传感器、ECU、执行器

1、电子控制单元（ECU，含软件）。ECU是汽车电子控制系统的大脑，它对各个传感器输入的电信号以及部分执行器反馈的电信号进行综合分析与处理，给传感器提供参考电压，然后向执行器发出控制信号，使执行器按照控制目标进行工作。
 软件系统集成存储在电子控制单元中，核心是微处理器，这种微处理器通常采用单片机，功能扩展容易，控制精度更高。完成数据采集、计算处理、输出控制、系统监控与自我诊断等。

2、传感器是汽车电子控制系统的信息采集者，类似于人类的眼睛耳朵...它将汽车的各种物理参量转变为电信号，并输送给电子控制单元。

3、执行器是汽车电子控制系统的执行者，类似于人类的手和脚，电子控制单元就是通过执行器实现对被控制对象的控制。执行器对电子控制单元输出的控制信号做出迅速反应，使被控制对象工作在设定状态内。

三、汽车电子控制系统基本工作原理

汽车电子控制系统事先将一系列的指令程序存储在ECU中，这些指令程序在设计、制造时就已经确定，等待各个传感器输入信号。工作时，ECU将接收到的传感器信息与存储器内的“标准参数”进行比较，然后根据结果控制执行器采取相应动作。

四、汽车软件系统的开发过程

随着智能互联、自动驾驶、电动汽车及共享出行的发展，软件、计算能力和先进传感器正逐渐取代发动机的统治地位。与此同时，这些电子系统的复杂性也在提高。以当今汽车包含的软件代码行数（SLOC）为例，2010年，主流车型的SLOC约为1000万行；到2016年达到1.5亿行左右。复杂性正如滚雪球般越来越高，不可避免地导致了与软件相关的若干严重质量问题：这在近期若干起大规模车辆召回事件中屡有耳闻。根据ADAC（全德汽车俱乐部，德国最大的交通协会）统计，德国2004年有40%的车辆故障最终归咎于软件问题或电子部件故障。为此，必须在保证电子系统整体可控的前提下研发新功能，于是出现先拆解研发而后在集成的流程。

先将电子系统研发拆解为软件系统、硬件系统、传感器和执行器四大部分，经过V模型流程研发，最终再次集成。这个V模型涵盖了从系统层面到软件层面以及集成后的功能测试和系统测试等流程，是当今汽车行业广泛应用的开发流程。

软件开发流程：

1.分析终端客户需求、定义逻辑系统架构

这一步是根据终端客户的需求以及法规需求定义出整车软件系统的逻辑架构。其中包含各大功能块的定义，功能块接口定义和功能块之间的通信定义。这一步仅考虑满足原始需求，不会涉及任何技术层面的具体分析。

2. 分析逻辑系统架构需求、定义技术层面系统架构

逻辑系统架构为定义具体的技术层面系统架构提供了基础。在这一步中开始讨论具体的技术问题，哪些功能将通过软件实现、软件块分装在哪些电子控制单元以及电控单元之间采用什么通信协议等等。软件系统初现雏形。

3. 分析软件需求、定义软件架构

这里开始具体到电控单元中对于软件本身的需求分析。根据需求，定义出合适的软件架构。同时，还要考虑电控单元存储资源的最优使用、为满足安全法规的冗余系统设计等等。这里，会把软件进一步细分为更小的软件部件，定义各个部件之间的接口、分层和边界。

4. 定义软件部件

针对每个软件部件会继续定义出需求。这里的需求集中在功能层面，尚不考虑具体的软件实现方式等。

5. 设计、实现及测试软件部件

依据具体的需求，工程师开始分别搭建不同的软件部件。在前面一系列的拆解、分析和定义后，终于抵达了软件最核心最具体的世界——代码。与人们熟知的程序员直接写代码稍有区别，传统的汽车软件研发采用的是基于模型开发。如下图所示，逻辑运算通过模型的方式表达出来，相比于代码更加直观，便于日后的标定工作和维护。在一个电控单元中，有上千个这样的功能函数，如下图所示的功能模型组合到一起，会形成一份上万页的文件。这份文件是接下来所有流程的基础。

当然这套模型只是工程师之间便于交流的高级语言，最终它们会被人工或计算机转为代码进入控制器中工作。早年间，模型到代码中间的转换工作由人工完成。这造成的问题是，代码无法统一化和标准化。面对一个软件逻辑模型，程序员可以用多种方法完成代码编译工作，达到同样的功能效果。但是，代码运行所占用的硬件资源或严谨度会大不相同。因此，近年来转码工作逐渐被机器取代。软件工程师事先定义标准的编译规范，保证最终代码统一和标准。

每一个软件部件完成后，要进行相应的软件测试。这里还不会聚焦功能层面的测试，仅仅针对软件本身。例如软件中是否因设计不当产生死循环、每个信号定义的范围是否恰当、会不会造成溢出错误或者会不会出现除以零的运算情况等等。针对这些，工程师要事先定义测试方案，由计算机进行全方位全覆盖的软件逻辑测试。例如，对于if, else语句需要把每一种可能的情况都测试检查到。

6. 集成及测试软件部件

单一软件部件研发测试完成后，将它们集成到一起就形成了每个电控单元中完整的软件包。这套软件包在集成后依然需要测试，检查各部件之间是否兼容，是否有开放接口等等。

7. 系统集成及测试

当软件包集成测试结束，它们将被刷进每一个电子控制器中。每个控制器与相应的传感器、执行器等用线束相连，最后控制器之间接通总线通信。这样整套电子系统终于诞生。如新生儿一般，这套系统依然十分脆弱和稚嫩，还有很大的潜力等待被开发。

系统集成后的第一批测试往往是问题重重。因为系统高度复杂，各个研发部件被分工研发，即便之前有严格的测试流程，仍会有许多漏网之bug。如果分工研发的各部门之间没有在开发过程中充分交流，集成后可能会出现各类兼容性问题。针对每一个问题，工程师们都不会忘记前面提到的拆解和掌控。拆解表象问题，找到根源，修复软件bug，掌控整套系统。

8. 标定

系统测试结束后将进入软件标定阶段，这也是软件开发中的重要阶段。在软件实现阶段，工程师会在软件中预留一些可标定参数而不是固定的数值，等待标定。这是基于成本考量，车型繁多的整车厂不可能为每款车型单独开发一套软件系统。一般的解决方案是研发平台软件，适用于多款车型。然而每款车型都有自己的特点，平台软件无法让这些特点发光，标定可以。通过改变不同的参数数值，可以让车辆实现不同的驾驶性能，这也给了标定工程师很大的发挥空间。

9. 系统测试及接受度测试

标定完成后，就进入了整套流程的最终阶段。依据流程一开始提出的需求，忽略那些具体的技术实现手段，站在整个系统的高度检验它是否达到了终端客户的需求。到了这一步，整套软件系统已经十分成熟。在正式进入量产前会从一个时间点开始，停止所有软件和标定变更，为最终量产做准备。

整套V模型走下来可以看到，左侧和右侧的每个环节相互对应。需求为定义测试方案提供基础，而测试结果又会带动进一步的开发和完善。

你或许会问，如果从V模型的左上角好不容易一路走到右上角，结果最后一步测试发现当初第一步的系统构架出了设计问题，那岂不是为时已晚？难道还要一切重新来过？的确，软件系统十分复杂，研发周期长。如果只是沿着V模型慢慢悠悠从左到右走一遍，等最后一步才发现问题，那确实一切都来不及了。因此，在实际研发中会持续不断地集成、持续不断地测试，工程师们会把V模型从左到右重复走许多遍。

研发初期连原型车都还没有的时候，软件测试会依靠整车仿真系统在计算机中进行，发动机、变速箱、电子控制器、总线等都虚拟存在于工程师电脑中（SiL, Software in the Loop）。在仿真系统中，汽车可以如真实般开动，模拟各种工况提供给工程师测试。

随着车型研发推进，某些电子控制器研发完成，他们可以取代那些虚拟的电子控制器进入测试环境，但是其他部件仍为虚拟仿真（HiL, Hardware in the Loop）。直到有一天，原型车研发完成，软件集成和测试进入试验台架。最终，原型车调试完毕落地，软件测试进入实车阶段。可以说，软件开发的起始点非常早，从虚拟到现实一路走来，一直延续到最后的量产前夕。其实目的只有一个，通过不断集成和测试，尽可能发现所有问题，保证汽车的驾驶性、舒适性和安全性。

五、汽车电子软件发展趋势

1、 ECU整合度将提升

早在去年，大众就宣布力争让汽车上只有一个ECU。在一些供应商巨头内部，确实也在这么做。特别是在ADAS和自动驾驶下，整合的ECU架构尤为重要。

2、 ECU将承载更多的传感器

未来汽车将需要更多的传感器来感知环境，以及依靠传感器来保证冗余设计。这对ECU的能力来说也是考验。不过高级算法与机器学习的发展，有望取代一部分传感器，减少传感器数量。

3、 汽车以太网发展

长期以来，汽车ECU都是在一个封闭的网络环境下。不过随着智能汽车技术、物联网的发展，很有可能会催生汽车以太网，实现跨域通信。不过如何保证功能安全，这将又是对汽车软件的一大考验。

数据量的提升、HAD的冗余要求、互联环境下的安全保障，以及跨行业标准协议的需求很有可能催生汽车以太网，并使其成为冗余中央数据总线的关键助推因素。以太网解决方案可以实现跨域通信，并通过添加以太网扩展，例如音-视频桥接（AVB）和时间敏感网络（TSN）等，来满足实时性要求。

本地互联网络、控制器区域网络等传统网络将继续在车辆上运用，但仅用于封闭式的低级网络，如传感器和执行器等。FlexRay和MOST等技术有可能被汽车以太网及其扩展（如AVB、TSN等）取代。

4、整车企业会严控与功能安全及HAD相关的数据互连，但将为第三方访问数据开放接口

发送与接收安全关键数据的中央互联网关将始终直接且仅连接到整车企业的后台，第三方会被允许进行数据访问（被监管法规排除的场景除外）。然而，在车辆APP化的推动下，资讯娱乐系统的新兴开放接口将允许内容和应用程序供应商加载内容，而整车企业将尽可能严格地保持各自的标准。

目前的车载诊断端口将被互联通讯方案取代。通过接入整车物理端口来读取车辆数据不再必要，登陆车企后台即可。车企将在其后台开放若干数据接口，以满足若干特定场景的需求，如失窃车辆轨迹追踪或个性化保险等

5、汽车将在云端结合车内及车外信息

虽然非车企以外的企业参与程度仍取决于监管法规，非敏感数据（即非隐私或安全相关数据）仍然有望更多地在云端进行处理。随着数据量的增长，大数据分析将被越来越多地应用于数据处理，并将基于数据处理结果制定相应的行动方案。

基于数据的自动驾驶的应用及其他各项数字化创新将依赖于不同企业之间的数据共享。当然现在仍然不清楚不同企业间的数据共享将如何实现、由谁实现，但主要的传统供应商和技术企业已经开始建立有能力处理此种海量数据的集成化平台。

6、汽车将应用双向通信的可更新部件

通过车载测试系统，汽车可以实现自动检查功能和集成更新，从而推动生命周期管理，以及增强或解锁产品的售后功能。所有ECU都会与传感器和执行器交换数据，并检索数据包来支持创新性用例，如基于车辆参数的路线计算。

OTA更新是HAD的前提条件，它还将有助于开发新功能、确保网络安全，并使车企得以更快部署功能与软件。事实上，正是OTA推动了本文提及的多项整车架构上的重大变革。

为实现类似智能手机那样的升级性，汽车行业须克服限制性的经销合同、监管要求和安全与隐私问题等诸多挑战。整车企业将与该领域的技术供应商密切合作，在OTA平台上实现车队标准化。

车辆将在全寿命周期内获取功能性及安全性升级。监管部门可能强制要求软件维护，来确保车辆设计的安全完整性。更新和维护软件的责任将在车辆维护与运行领域催生新业务模式。

中国将成为汽车软件及电子产业发展的新高地

中国的整车行业在过去几年取得了有目共睹的巨大发展。国产汽车行业的进展不仅体现在传统能源汽车的研发及制造上，也同时体现在了诸如汽车电动化、共享化、互联网化、无人驾驶化等所谓“新四化”上。国产汽车软件及电子的发展，也会借此东风，不断取得新发展。

国内一些车企在上面软件发展趋势中也有所动作：

ECU整合：比亚迪早前宣布在最新的e平台上实现仪表、空调、音响、智能钥匙等控制模块10合1，使整车控制模块线束大幅减少，降低模块故障率以及提升生产装配效率。

汽车以太网：上汽集团早前推出了基于全新电子电气架构的电动车平台——Double E架构，核心亮点之一是采用了支持海量数据极速传输的以太网技术。

整车厂商开放数据接口：比亚迪早前上线了汽车智慧开放平台，并通过该平台将车内信号封装为数百个API。开放的API内容涵盖车身、行驶数据、车速、全景、空调、雷达、充电设备等18类数据。

云端数据处理：阿里巴巴推出的AliOS智联网汽车解决方案，其一大亮点是充分发挥了阿里云在云计算、大数据和人工智能的优势，借助阿里巴巴的生态能力，赋能合作伙伴更好探索“数据x智能”驱动的新型业务模式。

OTA：上汽与阿里巴巴合作的斑马智行在2017年底/2018年初完成对近40万台荣威/MG品牌乘用车的OTA升级，受到了业内极大关注，堪称是智能汽车在华发展的标志性事件之一。

汽车软件和电子系统的新时代已经开启。此前业内奉为圭臬的业务模式、客户需求和竞争格局都将发生剧变。我们对即将产生的产值和利润持乐观态度。但若想从变革中获益，汽车行业的所有参与者均应根据全新的环境，重新思考和谨慎定位（或再定位）自身的价值主张。