汽车上看不见的软件系统（深度剖析）

下图是一个抽象出来的控制模型。驾驶员通过方向盘、踏板和换挡杆等给出期望（W*）操控汽车。这一系列实实在在、看得见摸得着的期望被转化为抽象的电子信号（W）进入电控单元。随后电控单元通过比较驾驶员期望（W）和传感器传回的当前实际值（R）进行对比。若对比发现，期望与现实存在差距，电控单元中的软件程序会通过逻辑计算给出指令（U）操控执行器做出响应（Y）。控制对象在执行器的动作和环境的影响（Z）下，开始做出驾驶员期待的反应（X）。这一反应（X）又会通过传感器监控、感知，当前状态（R）将再次返回电控单元完成控制闭合回路。


（控制模型）

听起来十分复杂抽象，这里举一个刹车辅助系统的例子来说明。

紧急刹车时，如果驾驶员脚力不足或反应较慢，没有及时将刹车完全踩死、踩满会导致刹车系统无法全力工作，在这种情况下这套系统就将被激活。在驾驶员刹车踏板输入不变的前提下，自动提高制动力使汽车更快减速。

例如，行车中遇到紧急情况，驾驶员抬起油门后，快速用力地踩下刹车踏板期望汽车迅速减速（W*）。刹车踏板通过采集踏板值变化率、踏板受力等信号（W）得到驾驶员踩刹车踏板的轻重、缓急等信息，理解驾驶员意图。W作为电子信号传入相应的电控单元中。同样传入电控单元的还有传感器的实时测量数据（R），例如当前轮胎转速或车速。若软件通过比较发现，当前轮速高、车速快、减速度不足，驾驶员踩下的刹车踏板深度不足以让刹车系统发挥出最大功能，最终得出液压制动系统需要进一步刹车的结论（U）。


（电子控制单元）

位于轮胎附近的制动卡钳接到指令（U）开始工作让轮胎转速变慢。结果由于路面结冰的影响（Z）车轮在强制动力的作用下开始抱死打滑，一系列制动工作没有让汽车达到预期的减速效果。传感器将发生的这一切以电子信号的形式通过通信线束（R）实时传回电控单元。软件逻辑将因此激活防抱死系统ABS，操控制动系统做出响应并不断接受传感器的控制反馈，最终达到让汽车减速这一驾驶员期望。

这一次次的控制，在电控单元中以10ms甚至更快的速度循环进行着。


（电子控制单元及其剖面图）

以上是一个十分简单的电控例子，只有一个电控单元参与其中。而现如今许多复杂的汽车功能常常需要由多个电控单元、多个传感器联合控制才能实现。

例如自适应定速巡航功能ACC，驾驶员通过设定期望巡航速度、与前车保持的期望距离等实现驾驶辅助系统一定程度上接管汽车的功能。这一功能就需要多个电控单元协作完成并且通过总线让它们随时保持通信联系。ACC控制器、雷达控制器、发动机控制器、ESP控制器、变速箱控制器、人机交互控制器以及数不清的传感器和执行器都将参与其中。

可以说，软件和硬件系统相互合作，共同为汽车创造出一个个新的功能奇迹。

2、软件系统的出现

急剧攀升的软件代码量、庞杂的总线通信导致汽车电子系统日渐复杂。

根据ADAC（全德汽车俱乐部，德国最大的交通协会）统计，德国2004年有40%的车辆故障最终归咎于软件问题或电子部件故障。为此，必须在保证电子系统整体可控的前提下研发新功能，软件工程师绝不能容忍自己迷失在亲手创建的庞大系统中。

正如汽车行业的那句老话：Divide et Impera！维基百科对应的中文词条将它翻译为“分而治之”。德语将这句拉丁语翻译为Teile und beherssche！，直译中文是拆解和掌控。

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

下面将以下图所示的软件系统开发为例，分步骤介绍V模型。

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

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

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

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

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

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

4、定义软件部件

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

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

依据具体的需求，工程师开始分别搭建不同的软件部件。在前面一系列的拆解、分析和定义后，终于抵达了软件最核心最具体的世界——代码。与人们熟知的程序员直接写代码稍有区别，传统的汽车软件研发采用的是基于模型开发。

如下图所示，逻辑运算通过模型的方式表达出来，相比于代码更加直观，便于日后的标定工作和维护。在一个电控单元中，有上千个这样的功能函数，如下图所示的功能模型组合到一起，会形成一份上万页的文件。这份文件是接下来所有流程的基础。

当然这套模型只是工程师之间便于交流的高级语言，最终它们会被人工或计算机转为代码进入控制器中工作。

早年间，模型到代码中间的转换工作由人工完成。这造成的问题是，代码无法统一化和标准化。面对一个软件逻辑模型，程序员可以用多种方法完成代码编译工作，达到同样的功能效果。

但是，代码运行所占用的硬件资源或严谨度会大不相同。因此，近年来转码工作逐渐被机器取代。软件工程师事先定义标准的编译规范，保证最终代码统一和标准。

每一个软件部件完成后，要进行相应的软件测试。这里还不会聚焦功能层面的测试，仅仅针对软件本身。

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