软件定义汽车2-汽车软件开发与方法（软件定义汽车概念）

现代汽车已经从一个机械设备演变成一个依赖软件正确运行的分布式信息物理系统。

从利用软件来优化车辆表现到车载娱乐系统的编辑，软件为汽车行业的发展带来了大量的新机遇。现代汽车中分布着各类电子设备，而一个遍布着各类软件产品的汽车平台，也一定是消费者喜闻乐见的。

来自老美的特斯拉，披着汽车制造的软件公司，它以软件驱动创新而闻名，通过持续向车辆推送软件更新，使车主每天都可以享受到最新的车辆功能。（个人觉着百分之七八十的车主都是因为这点选择的特斯拉，毕竟哪位司机朋友不想着天天老车新开）

密集的软件系统带来了新的机遇，但必须意识到的是，在这些软件发布给用户之前，必须要经过更细致的设计、实施、验证和确认工作。近几年来，国外特斯拉、国内“蔚小理”等造车新势力的出现，可以明显发现，机械工程对汽车工业发展的主导性正在逐渐降低，而电子和软件工程正在逐渐掌握话语权。

二、

软件架构与软件工程

严格的软件工程流程可以在保证不额外增加系统复杂性的前提下提升软件质量，并确保这些代码不会在交通场景下导致致命的危害。在软件工程中，一个重要的环节是软件系统的高层设计，这种概念用更通俗易懂而统一的称呼，可以称呼为软件架构。

一个软件的架构可以为软件设计者提供一个规范框架，告诉他们一个软件功能是怎样拆分为各个软件组件以及这些组件之间又是如何交互的。

软件架构的设计通常在软件开发的早期阶段就已完成，是将其作为软件被拆分为组件以及功能被系统化到不同组件的基础依据。早期的汽车工业，车辆上并不存在电子产品，直到上个世纪70年代，为了顺应市场对提升燃油效率的诉求，电子喷油装置被应用在了汽车上，拉开汽车电子化的序幕。

在最初的10年时间里，大部分的汽车软件都是深度嵌入某单一功能域内的电子装置中，例如动力总成系统中的电子燃油喷射装置，电气系统中的中控锁、电子点火装置等。由于当时车辆的电子设备较少，而车辆的安全功能又通过机械的方式得到保障，因此汽车软件的架构通常是整体式的，不同设备的软件之间并不存在通信交互。

在1980年代，如中央计算机等创新不断出现，使得车辆一些基本行驶数据可以被读取和显示，人机交互进入了新的篇章。在嵌入式软件方面，一些受软件算法控制的新功能出现，如ABS防抱死制动系统和电子变速器等。

在1990年代，更多消费者可见的电子功能出现，最值得注意的便是车载信息娱乐的导航系统等，车辆信息的实时可视化意味着更多重要电子组件的整合，如动力总成的控制器、GPS信号接收器以及信息娱乐显示等设备之间进行数据的交互。

在2000年代初，经过20年的快速发展，汽车软件已经成为汽车行业创新的主导因素，大量的硬件导致大量的软件，造成了人力物力的极大浪费，AUTOSAR标准的应运而生，它的出现为汽车软件架构提供了开放式的解决方案，当相同软件应用到不同硬件平台时，所需要进行的软件变更大幅减少，就好像汽车中的计算机引入了一个普适的操作系统，让不同汽车制造商可以方便地共享同一功能组件。

在此之前，汽车软件都是基于某一独立的车辆内部网络的分布式结构进行设计的，现在，一种全新的汽车电子设计方法被提出，无线汽车的概念被提出，车与车通信、车与基础设备通讯，以为无人驾驶成为软件架构发展的推动力，一些新成员粉墨登场，售卖给消费者的汽车不再是最终产品，而是一个可以在全生命周期随时部署新功能平台，特斯拉的汽车产品就是这一理念的先行者。

三、

汽车软件开发过程

需求过程是软件开发流程生命周期中的初始阶段，软件产品的质量定义为，软件满足用户需求、隐形期望和专业标准的程度，这足以说明需求对软件质量的重要影响。（专门研究人员在奔驰的研究中表明，一辆现代汽车的需求规格说明如果拆分到组件层面，总长度可达到十万页的数量级，这些需求文档会被分发到数量庞大的供应商，用于开发各自ECU产品）

汽车软件的架构和高层描述通常属于OEM的业务范畴。OEM会决定他们设计的车辆具备哪些功能以及哪些需求是嵌入在软件及电气系统中的。它们还负责将系统层面的需求分解为特定软件组件的需求，然而，软件组件的详细设计及后续的实施则是供应商（包括Tier-1、Tier-2和Tier-3）或OEM内部软件开发团队负责的领域。他们需要进行软件组件的需求解读，组件架构设计，软件的实施、集成及测试，然后将软件交付至OEM。

软件开发流程是汽车软件开发过程中的核心，软件开发流程为软件开发实践提供了一个骨架并确保了它的严谨性。软件开发的流程包含“阶段”“活动”和“任务”三个要素，它们规定了参与者需要完成的工作，总体上看，上述各阶段可以排列成V（Verification和Validation模型）型曲线，它取材自多个国际工业标准，例如 ISO / IEC 26262等，常被用于安全关键系统的开发。

设计，V型开发流程的左侧，

将整车层级逐步分解到组件层级的需求，俗话说万事开头难，需求工作做足且后期不变更，可以更有效的保证后期任务在有效时间节点内完成。

AUTOSAR是汽车软件研发的重要灵感源泉，因此，当我们探讨软件需求时，不妨先看看AUTOSAR标准中的需求格式。在该标准中，需求大多以文本形式出现。需求的结构并没有什么特殊之处，和一般意义上的需求类似，它包含了需求的描述、理由和用例。

文本需求被用于描述车辆的最高级别属性，通常在两个阶段出现，一是需求阶段，用于定义高层车辆功能规范，另一个则为组件设计阶段，用于制定大规模软件需求规格说明。

定义文本类型需求的工作很少是从零开始的。它们通常是基于模型制定，被用来在模型的基础上进一步描述软件系统的内部工作细节。

当要传递需求的概览或提供需求的上下文时，需要用到另外两种需求的表现形式是“用例”和“模型”。

用例描述了在规格说明下一个参与者和系统之间的一系列交互。下图所示的是用例的例子，参与者在用例“无钥匙启动”中与车辆进行交互。相应的图表被用来表示存在哪些交互以及这些交互过程中包含多少参与者。

在汽车工业，用例形式的需求规格说明最常见的应用场景是描述车辆功能的依赖关系，即为实现某个特定的用例，参与者(驾驶员或其他道路车辆）和被设计的车辆（系统）之间是如何交互的。基于用例的需求规格说明通常使用如图所示的UML序列图进行描述。

另一种能为需求提供更多上下文表达方式的是模型，这种方式一般可以采用两种格式，类似于UML的模型和Simulink模型。

建立良好的需求和构建元素数据库是汽车软件工程成功的关键，这是由于汽车市场的可变性基础上，即软件产品必须具备可配置性，作为消费者，我们肯定是希望自己的车可以配置最新的最强大的硬件、电子系统及软件功能。

除此之外，仍然需要将硬件与硬件、软件与软件以及最终的软件硬件集成在一起，再进一步集成到整车电子电气系统中。

需要注意的是由于不同的软件模块开发可能以不同的步长来进行，因此集成步骤也不是同时集成的。

测试，V型开发流程的右侧，

需求始于高的抽象层级，并逐渐向更细节更低的抽象层级发展。而测试则正好相反，测试工程师会从单元测试（最小的颗粒度）开始执行，对逐个函数或逐行代码进行测试。进一步，他们将对整个组件进行测试（即将多个单元连接在一起），最后再向整个系统实施及单元测试和车辆整体功能测试推进。

以下对各阶段的测试进行简单说明，单元测试是最基本的测试，在独立的软件上执行，单元测试的目标是发现与源代码中的原子级功能及方法的实施有关的缺陷。自动化测试用例是单元测试的常用方案。测试用例将个性化的方法和达成期望质量所必需的数据相结合。在执行测试后，再将测试结果和期望结果对比。当发现测试用例中的某个问题，利于快速描述缺陷位置甚至给出缺陷修复意见。

组件测试有时也称为集成测试，其目的是测试某组件内不同单元问题代码的集成。组件测试和单元测试的主要区别在于，根据不同的工况来模拟被测组件或者组件组合的运行环境。在汽车系统中，组件测试通常采用软件建模工具（Model-In-the-Loop，MIL,软件/模型在环）或者硬件模拟器（Hardware-In-the-Loop，HIL，硬件在环）来模拟测试环境，又由于组件测试在模拟环境下进行，非功能特性通常是无法被测试的，若想测试的话则需要模拟的细节非常详细，这会带来更高昂的测试成本。（笔者从事的行业中，若使用通用的HIL设备价格是一个数，若要实现自己期望而冷门的需求，则需要另附额外的资金，会使得整套HIL设备十分昂贵）

系统测试是在整个系统集成完成之后，将系统作为一个整体进行测试的阶段。系统测试的目标是在多个维度上检查系统是否满足规格说明中的要求。所验证为的维度包括，1.是否具备规定的功能；2.是否可以与其他独立系统交互；3.是否可以继续扩展；4.高负载下是否可以运行；5.是否满足性能要求；6.可靠性是否达标；7.是否符合法律法规要求。（在汽车领域，此类测试一般使用具有完备电器系统且没有地盘和硬件设备的实验台架来进行完成）

功能测试式验证系统的功能是否按照规格说明书要求正常运行，作为对采用用例形式定义的功能需求的回应，以下以一个测试用例来进行说明。

除此之外，还有安全测试以及迭代测试。

从以上说明可以总结的到设计位于V型的左半边，测试位于右半边，不同的阶段可以总结为，

1、需求 (requirements engineering)：该阶段用于创建有关软件功能的设想并将设想分解为多个需求（关于应该实现什么的碎片化信息）。

2、软件分析 (sofiware analysis)：该阶段用于执行系统分析，做出关于将功能分配到系统中不同逻辑部分的高层级决策。

3、软件架构设计 (software architecting)：该阶段，软件架构师将描述软件区其组件的高层设计，并将这些组件分配至相应的计算节点(ECU)。

4、软件设计 (software design)：该阶段用于软件各组件的详细设计。

5、实施(implementation)：在该阶段，用相关的编程语言实施组件的设计。

6、测试 (testing)该阶段，软件以多种方式进行测试。

四、

软件开发的详细设计方法

在实际的软件开发方法中，目前市面上最主流并且广泛使用的方法是基于MathWorks公司出品的商用软件Matlab中的Simulink可视化工具来进行汽车嵌入式系统的建模、仿真和集成。

汽车软件设计中使用的模型通常反映了汽车功能的行为，因此，模型是在能够反映物理世界而非软件世界的形式体系内创建的。其过程如下图所示。

下面描述一个经典的ABS实例(使用Matlab/Simulink可视化工具)。

首先，在设计过程的开始，汽车的功能被描述为一个数学函数，函数的输入和输出被数据流所定义，表明使用数学模型来描述汽车功能。

此过程中需要将车轮的打滑、力矩和速度的相关物理过程描述为以时间为自变量的函数（或多个函数)。

当确定好数学上的描述之后，将所有的方程翻译成一组Simulink模块。在将数学方程转换为Simulink模块和函数的过程中。需要关注的是数据的流动方向和反馈回路，例如，在ABS示例模型中，车轮的打滑取决于车速，车速反过来又与车轮滑移有关。

若Simulink库中不包含的功能，需要通过现有的模块或在Matlab中手写代码，以描述一些标准库中不包含的功能，完成建模和测试之后，完成建模和软件的一些测试工作之后，模型将被生成为目标语言代码（通常是C 或者C 具体选择取决于系统要求）。

下为MathWork文库中防抱死制动系统ABS模型，此示例说明如何建立一个简单的防抱死制动系统ABS模型。

它对车辆在紧急制动状况下的动态行为进行仿真，此模型使用理想的防抱死制动控制器，该控制器使用基于实际滑动与期望滑动之间的误差控制。

在施加制动之前，车轮以对应于车辆速度的初始角速度旋转。使用单独的积分器来计算车轮角速度和车辆速度。同时使用两个速度来计算滑动，引入了用角速度表示的车辆速度。

根据下述表达式，可以看出当车轮速度与车辆速度相等时，滑动为零；当车轮锁定时滑动等于1。合适的滑动值为0.2，这意味着在车辆速度相同的情况下，车轮转数等于非制动状况下转数的0.8倍。这将最大限度地提高轮胎和道路之间的粘附，并通过可用摩擦最大限度地缩短停止距离。

轮胎和道路表面之间的摩擦系数mu是滑动的经验函数，称为mu-slip曲线。使用Simulink查找表将MATLAB变量传递到模块图中来创建mu-slip曲线。

模型将摩擦系数mu乘以车轮上的重量W来得到作用在轮胎圆周上的摩擦力Ff。车辆质量除以Ff可得出车辆减速度，模型对其进行积分以获得车辆速度。

将期望的滑动值设置为mu-slip曲线达到峰值时的滑动值，这是使制动距离最小化的最优值。

子系统Wheel Speed为，

下图显示了ABS仿真结果。图中的第一个图显示了车轮角速度和相应的车辆角速度。此图表明，在未锁定的情况下，车轮速度始终低于车辆速度，车辆速度在不到 15 秒的时间内变为零。

该种建模的方法可以称为“基于模型的设计方法-MBD，Model Based Design”，采用的是图形化设计和自动代码生成，是不同于基于手工编程和纸上规范的传统变成方法。

五、

总结

在本期主要内容中，介绍了为什么发展汽车软件工程、目前主流的汽车软件开发流程以及简单说明了基于MBD开发方法。

回顾历史，从1970年的简单发动机控制算法，到2000年的先进安全系统，到2010年的先进车联网技术，2020年的自动驾驶算法技术，汽车的软件数量明显增加，且呈指数上升，汽车软件技术革新带来很多挑战的同时也带来了大量的新机遇。最后，借用博世的一句话“毫无疑问，我们必须以持续改善现状为目标，必须一致努力做到更好，而不是安于现状”。