现代汽车软件架构与软件工程严格的软件功能是什么

菏泽炫佑科技

现代汽车软件架构与软件工程严格的软件功能是什么

从使用软件优化车辆性能到编辑车载娱乐系统，软件给汽车行业的发展带来了丰富的新机遇。 现代汽车中分布着各种各样的电子设备，充满各种软件产品的汽车平台必然受到消费者的欢迎。

特斯拉，来自美国，是一家制造汽车的软件公司。 它以其软件驱动的创新而闻名。 通过不断向车辆推送软件更新，车主每天都可以享受到*新的车辆功能。 （我个人认为70%到80%的车主都是因为这个选择特斯拉的，毕竟哪个司机不想每天开一辆新车）

密集的软件系统带来了新的机遇，但必须认识到，在这些软件发布给用户之前，必须完成更详细的设计、实现、验证和确认工作。 近年来，随着国外特斯拉、国内“威小力”等造车新势力的出现，可以明显看出机械工程在汽车工业发展中的主导地位正在逐渐下降，而电子和软件工程正在逐渐获得话语权。 。

二，

软件架构和软件工程

严格的软件工程流程可以在不增加额外系统复杂度的情况下提高软件质量，并保证这些代码在交通场景中不会造成致命危险。 在软件工程中，一个重要的环节是软件系统的高层设计。 这个概念可以用一个更容易理解和统一的名字来称为软件架构。

软件架构可以为软件设计者提供规范框架，告诉他们软件功能如何划分为各个软件组件以及这些组件如何相互交互。

软件架构的设计通常在软件开发的早期阶段完成，是软件拆分和功能系统化的基础。 汽车工业发展初期，车上并没有电子产品。 直到20世纪70年代，为了顺应市场对提高燃油效率的需求，电子燃油喷射装置被应用到汽车上，拉开了汽车电子化的序幕。

在*初的10年里，大多数汽车软件都深度嵌入到单一功能域内的电子设备中，例如动力总成系统中的电子燃油喷射装置、中控锁、电气系统中的电子点火装置等。 由于当时车辆中的电子设备很少，且车辆的安全功能都是机械保证的，所以汽车软件的架构通常是单体式的，不同设备的软件之间没有通信交互。

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

20 世纪 90 年代，出现了更多消费者可见的电子功能，其中*引人注目的是车载信息娱乐和导航系统。 车辆信息的实时可视化意味着集成更重要的电子元件，例如动力总成控制器。 GPS 信号接收器和信息娱乐显示器等设备之间的数据交互。

2000年代初，经过20年的快速发展，汽车软件已成为汽车行业创新的主导因素。 大量的硬件导致了大量的软件，造成了人力、物力的巨大浪费。 标准应运而生。 汽车软件架构提供了一个开放的解决方案。 当相同的软件应用于不同的硬件平台时自动化软件开发，所需的软件改动就大大减少，就像汽车中的电脑引入了通用操作系统一样，让不同的汽车制造商可以轻松共享相同的功能组件。

在此之前，汽车软件是基于独立的车辆内部网络的分布式结构来设计的。 现在，提出了一种新的汽车电子设计方法，提出了无线汽车的概念，车与车之间的通信，车与车之间的通信，与基础设备的通信，认为自动驾驶已经成为自动驾驶的驱动力。软件架构的开发。 一些新成员也首次亮相。 卖给消费者的汽车不再是*终产品，而是一个可以在整个生命周期中随时部署新功能的平台。 Tesla La 的汽车产品是这一理念的先驱。

三，

汽车软件开发流程

需求过程是软件开发过程生命周期的初始阶段。 软件产品的质量定义为软件满足用户需求、隐含期望和专业标准的程度。 这足以说明需求对软件质量的重要影响。 （专业研究人员在梅赛德斯-奔驰的研究中表明，如果将现代汽车的需求规格细化到零部件层面，总长度可达十万页的量级。这些需求文档将分发到一个大量供应商。开发各自的 ECU 产品）

汽车软件的架构和高级描述通常属于 OEM 的业务范围。 原始设备制造商将决定他们为车辆设计哪些功能以及软件和电气系统中嵌入哪些要求。 他们还负责将系统级需求分解为特定软件组件的需求； 然而，软件组件的详细设计和后续实现是供应商（包括 Tier-1、Tier-2 和 Tier-3）或 OEM 内部软件开发团队负责的领域的责任。 他们需要解释软件组件的需求，设计组件架构，实施、集成和测试软件，然后将软件交付给 OEM。

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

设计上，左边的V型开发流程，

将需求从整车层面逐步分解到零部件层面。 俗话说，万事开头难。 如果你对需求做了足够的工作并且以后不再更改，那么你可以更有效地保证后面的任务在有效的时间节点内完成。

它是汽车软件开发的重要灵感来源。 因此，我们在讨论软件需求时，不妨看一下标准中的需求格式。 在本标准中，要求大多以文本形式出现。 需求的结构没有什么特别的。 它类似于一般意义上的需求。 它包含需求、原因和用例的描述。

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

定义文本类型要求的工作很少是从头开始完成的。 它们通常是基于模型制定的，用于基于模型进一步描述软件系统的内部工作细节。

当传达需求概述或提供需求上下文时，需求的另外两种表示形式是“用例”和“模型”。

用例描述了参与者和规范下的系统之间的一系列交互。 下面显示的是一个用例示例，其中参与者在用例“无钥匙启动”中与车辆进行交互。 相应的图表用于表示存在哪些交互以及这些交互涉及多少参与者。

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

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

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

此外，还需要将硬件与硬件、软件与软件、*后软件与硬件进行集成，然后进一步集成到车辆电子电气系统中。

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

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

需求从较高的抽象级别开始，逐渐发展到更详细和较低的抽象级别。 测试则恰恰相反。 测试工程师将从单元测试（*小粒度）开始，逐个功能或逐行代码进行测试。 此外，他们将测试整个组件（即将多个单元连接在一起），*后进行整个系统实施和单元测试以及整体车辆功能测试。

下面简单介绍一下各个阶段的测试情况。 单元测试是*基本的测试，在独立软件上执行。 单元测试的目标是发现与源代码中原子级函数和方法的实现相关的缺陷。 自动化测试用例是单元测试的常见解决方案。 测试用例将个性化方法与实现所需质量所需的数据相结合。 执行测试后，将测试结果与预期结果进行比较。 当测试用例中发现问题时，快速描述缺陷的位置，甚至提供修复缺陷的建议是有帮助的。

组件测试有时称为集成测试，其目的是测试组件内不同单元问题代码的集成。 组件测试与单元测试的主要区别在于，根据不同的工况来模拟被测组件或组件组合的运行环境。 在汽车系统中，组件测试通常使用软件建模工具（模型在环、MIL、软件/模型在环）或硬件模拟器（在环、HIL、硬件在环）进行模拟。 -循环）。 测试环境，由于组件测试是在模拟环境中进行的，非功能特性通常无法进行测试。 如果要测试的话，就需要对细节进行非常细致的模拟，这会带来更高的测试成本。 （在笔者从事的行业中，如果使用通用的HIL设备，价格就是一个数字，如果要实现自己预期但冷门的需求，则需要附加额外的资金，这将使整套设备HIL 设备非常昂贵）

系统测试是整个系统集成完成后对系统进行整体测试的阶段。 系统测试的目的是从多个维度检查系统是否满足规范中的要求。 验证的维度包括： 1、是否具有规定的功能； 2、能否与其他独立系统交互； 3、是否可以继续扩张； 4、能否高负载运行； 5、是否满足性能要求； 6、可靠性是否符合标准； 7、是否符合法律法规的要求。 （在汽车领域，此类测试一般是使用电气系统完整且没有地板和硬件设备的实验台来完成）

功能测试验证系统的功能是否按照规范正常运行。 作为对以用例形式定义的功能需求的响应，使用测试用例来说明以下内容。

此外现代汽车软件架构与软件工程严格的软件功能是什么，还有安全测试和迭代测试。

从上面的描述可以总结出，设计位于V的左半部分，测试位于V的右半部分。 不同的阶段可以概括为：

1.需求（）：此阶段用于创建有关软件功能的想法，并将该想法分解为多个需求（有关应实现什么的碎片信息）。

2. 软件分析 ( )：此阶段用于执行系统分析并做出有关将功能分配给系统不同逻辑部分的高级决策。

3. 软件架构设计（ ）：在此阶段，软件架构师将描述其在软件区域中的组件的高层设计，并将这些组件分配给相应的计算节点（ECU）。

4. 软件设计（ ）：该阶段用于软件各组成部分的详细设计。

5.实现（）：在这个阶段，使用相关的编程语言来实现组件的设计。

6.测试（） 在这个阶段，对软​​件进行各种方式的测试。

四、

软件开发详细设计方法

在实际的软件开发方法中，市场上*主流、应用*广泛的方法是基于公司生产的商业软件中的可视化工具对汽车嵌入式系统进行建模、仿真和集成。

汽车软件设计中使用的模型通常反映汽车功能的行为，因此，模型是在反映物理世界而不是软件世界的形式主义中创建的。 流程如下图所示。

下面描述了一个经典的 ABS 示例（使用/可视化工具）。

首先，在设计过程之初，将汽车的功能描述为数学函数，并通过数据流来定义函数的输入和输出，表示使用数学模型来描述汽车的功能。

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

确定数学描述后，所有方程都被转换为一组模块。 将数学方程转换为模块和函数的过程。 需要关注的是数据流向和反馈循环。 例如，在 ABS 示例模型中，车轮滑移取决于车速，而车速又与车轮滑移相关。

如果有库中未包含的函数，则需要使用现有模块或手写代码来描述标准库中未包含的一些函数。 完成建模和测试后，在完成软件的建模和一些测试后，模型将生成为目标语言代码（通常是C或C++，具体取决于系统需求）。

以下是库中的防抱死制动系统ABS模型。 此示例展示了如何构建简单的防抱死制动系统 ABS 模型。

它模拟车辆在紧急制动条件下的动态行为。 该模型使用理想的防抱死制动控制器，该控制器基于实际滑差和期望滑差之间的误差进行控制。

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

根据以下表达式可以看出，当轮速等于车速时，滑移为零； 当车轮抱死时，滑移等于1。合适的滑移值为0.2，这意味着在相同车速下，车轮转数等于非制动情况下转数的0.8倍。 这将*大限度地提高轮胎和道路之间的附着力，并通过可用摩擦力*大限度地减少停车距离。

轮胎与路面之间的摩擦系数mu是滑移的经验函数，称为mu滑移曲线。 使用查找表将变量传递到框图中以创建 mu 滑移曲线。

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

将期望滑差值设置为mu滑差曲线达到峰值时的滑差值，即制动距离*小的*优值。

子系统轮速为，

下图为ABS仿真结果。 图中的**幅图显示了车轮角速度和相应的车辆角速度。 该图显示，在解锁状态下，轮速始终低于车速，并在不到 15 秒的时间内降至零。

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

五，

总结

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

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

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等