摘要： 汽车行业的软件开发遵循着非常严格的准则，主要侧重于乘客和行人的安全。最常用的开发生命周期之一是V模型，这是一个非常严谨但因此也非常缓慢且昂贵的过程。它对于批量生产非常有效，但对于原型开发来说并不方便。

本文的目的是构建一个专门用于小批量生产、展示车和原型车的新开发工作流程。

我的工作的第一部分是在Vector PREEvision中建模一些测试组件，并导出生成的ARXML文件。

然后开发了一个Python脚本和一个C++库；该脚本的目的是解析ARXML文件并导出所有需要的信息，而C++库则为程序员提供了便捷访问CAN网络以及上述文件中描述的消息和信号的途径。

最后，编写了一个演示程序并在开发板上运行，利用该库通过模拟其控制ECU来控制批量生产的前大灯。

总之，事实表明，以有限的努力用C++开发和部署ECU是可行的，有望为更轻松、更便宜、更快的汽车原型开发铺平道路。

01. 背景

车辆中电子设备的历史与技术本身的发展息息相关。第一个电子发动机控制模块至今已有近50年的历史。如今，一辆汽车中发现的电子控制单元（ ECUs ）的数量可高达150个。

随着系统变得越来越复杂，许多编码标准和指南应运而生，例如 MISRA ，它涵盖了C和C++。

虽然汽车架构通常使用V模型开发，但本工作的范围是找到一种专门用于原型开发和小批量生产的替代模型。然而，在此之前，需要介绍一些概念。

1.1 V模型

汽车行业最常用的开发模型之一是V模型。也称为V循环，它是一个非常稳健的模型，由两个不同的阶段组成；左侧代表项目定义阶段，而右侧对应验证阶段。每个行业对这两侧的划分都略有不同。

汽车行业通常将左侧分为三个部分：设计、开发和集成。每个步骤都从一份正式文件开始，以另一份正式文件结束，允许不同的参与方以最小的重叠执行每个步骤。

相反，右侧涉及对左侧相应步骤的验证。在每个步骤中，都会根据规范对结果进行验证，必要时返回到相应的阶段。

在设计阶段，定义软件和网络架构。定义所有软件组件及其交互，选择ECU的数量及其网络拓扑；最后，确定软件组件如何分布在ECUs上。

开发阶段包括所有ECU软件的设计和实现。与其他步骤一样，这通常是按照AUTOSAR指南进行的，稍后将对其进行解释。

最后，集成阶段包括将所有软件部分组合在一起并部署到物理ECUs上。

关于V模型需要记住的一点是，验证不仅在右侧进行，而且贯穿于开发生命周期。

在处理批量生产车辆时，这些步骤通常外包给不同的实体。模型本身的稳健性保证了最终结果符合要求。

图1.1:Vector根据其自己的软件解释的V模型

1.2 AUTOSAR

AUTOSAR（汽车开放系统架构）是汽车和软件行业领先公司的全球合作伙伴关系，旨在为智能移动开发和建立标准化的软件框架和开放的E/E系统架构。

AUTOSAR旨在标准化软件模块和应用程序接口，使组件更容易重用，甚至在不同制造商之间也是如此。

然而，许多AUTOSAR标准源于已经建立的OEM实践，因此它们允许多种变体，以适应制造商已经在做的事情，从而限制了互操作性。一个这样的例子是 E2E 协议，将在1.2.2节中解释。

需要注意的一点是，AUTOSAR仅提供每个软件模块的规范，而实现留给制造商，尽管某些组件的开源实现确实存在。

1.2.1 ARXML文件格式

AUTOSAR还定义了一种在兼容软件之间交换架构工件的格式，称为ARXML。ARXML文件只不过是具有特定语法的XML文件。

根元素始终称为AUTOSAR，包含零个或多个包。

包是相同类型元素的容器，可以嵌套。每个包和元素都有一个嵌套的SHORT-NAME标签，其中包含其名称。

节点可以包含对其他节点的引用，但与传统XML不同，层次结构不是通过标签名来探索的，而是通过SHORT-NAME内部文本。根引用是/，更深的节点通过在其父引用中添加/和相应的SHORT-NAME来引用。

例如，在清单1.1的第23行，可以找到对从第33行开始的元素的引用，而第16行上元素的引用是/Communication/ Frames /Test_CANFrame。

清单1.1：测试ARXML文件的摘录

包的名称没有标准化，尽管有些在工具之间是常见的。这意味着可以建模的所有内容都可以序列化，但并非每个工具都能处理ARXML文件中包含的所有信息。

1.2.2 E2E协议

AUTOSAR定义的众多标准之一是E2E协议规范。它是一个额外的通信层，位于上层和下层通信层之间（见图1.2），其目标是为关键消息添加端到端保护（因此得名），以便能够检测常见的网络问题，如消息损坏、重复或丢失。

图1.2：发送方和接收方之间的E2E通信保护概述

目前，该标准描述了14种不同的配置文件。每个配置文件都有不同的用例，涉及所需的保护级别和基础通信网络，但它们中的每一个都实现了一个计数器，以检测重复、丢失或乱序的消息，以及一个循环冗余校验（ CRC ）以检测损坏的消息，而不管下层通信层中已经存在的任何保护。

1.3 CAN总线

控制器区域网络（也称为CAN总线）是最常用的车辆通信网络之一。其开发始于1983年，此后已由国际标准化组织（ISO）标准化。现代车辆通常至少包括两个或三个CAN网络，但数量可能更高。

CAN的优势包括稳健性、能够获得相对较高的数据速率以及较少的布线数量。尽管如今也在使用其他汽车通信网络，如FlexRay和以太网，但CAN仍然在行业中无处不在。其缺点包括较小的有效载荷（最多8字节）以及与较新替代方案相比速度较低。

CAN使用一对差分双绞线，称为CAN高（CANH）和CAN低（CANL），使其对共模噪声具有很强的耐受性，并有助于检测总线问题。它在每端用120Ω电阻端接，并具有显性状态（由设备主动驱动）和隐性状态（由电阻拉动）。

隐性状态表示逻辑1，而显性状态表示逻辑0。没有总线仲裁：在传输时，设备也在监听，并且在接收到的位与正在传输的位不同的情况下中止传输。由于所有设备都是同步的，并且同时对每个位进行采样，这意味着在一位上发生冲突的情况下，传输显性位的设备可以继续传输，而其他设备必须停止；这被用来建立消息优先级，ID较低的消息在发生冲突时优先。

该标准没有为CAN设定特定的比特率，允许速度从125kbps到1Mbps，较低的速度不易受干扰，因此允许更长的网络距离。

1.3.1 CAN帧格式

CAN不识别发送者（也不识别接收者），但每个消息都有一个ID（如前所述，它同时作为其优先级）。ID可以是11位长（在CAN基本帧格式中）或29位长（在CAN扩展帧格式中），并且这两种格式可以在同一总线上共存。

图1.3显示了两种格式，而表1.1解释了每个字段的含义。

图1.3：CAN基础（a）和扩展（b）帧格式

表1.1：CAN基础和扩展帧格式字段说明

1.3.2 CAN FD

CAN标准规定最大比特率为1Mbps，但也规定了CAN FD（灵活数据速率），允许速度高达5Mbps。

只要使用不同的ID集，CAN和CAN FD就可以在同一总线上共存。传统的CAN设备可以容忍CAN FD传输，因为仲裁阶段使用与传统CAN相同的比特率，仅在传输数据和CRC时切换到更快的速率。相反，CAN FD设备必须能够接收传统的CAN帧。

通过将ro位发送为隐性（逻辑1）来表示FD模式。添加了新的位以支持CAN FD的所有功能，但原理基本相同。最大有效载荷也增加到64字节，而传统CAN仅为8字节。CAN FD消息仍然可以使用标准和扩展寻址。

图1.4：不同大小和不同数据比特率的经典CAN帧和三个CAN FD帧的比较

1.3.3 SocketCAN

SocketCAN是Linux中CAN协议的实现。它是在Linux中处理CAN的事实上的标准，因为它取代了所有以前的实现，这些实现通常特定于某些CAN硬件。SocketCAN抽象硬件，提供套接字接口，很像TCP/IP套接字。当然，这两种类型的套接字并不相同，因为CAN有一些TCP/IP没有的特性和特点，反之亦然，但它们的用法尽可能相似，使用相同的系统调用，如bind、read、write等。SocketCAN由许多组件组成，如套接字本身、配置层、用户空间应用程序和虚拟CAN驱动程序。

套接字层是实现的核心。它抽象硬件，并为应用程序提供发送和接收消息、过滤消息、获取到达时间戳等的API。

相反，配置层处理CAN硬件的物理配置，允许设置速度、CAN FD支持、发送消息的回显等。可以通过用户空间应用程序（如ip）和应用程序的特定API访问配置层。

SocketCAN还提供用户空间应用程序，如cansend，允许用户从命令行发送CAN帧，candump，将在CAN接口上接收到的所有帧打印到控制台，等等。这些工具在开发和测试期间非常有用，以确保一切正常工作。

最后，SocketCAN还提供了一个名为vcan的虚拟CAN驱动程序，允许用户在软件中模拟一个或多个CAN接口，以便在不需要真实硬件的情况下模拟和测试CAN通信。在开发过程中，结合用户空间应用程序，大量使用了此功能来在本地测试所有内容，然后再将软件部署到真实硬件上。

02. 系统设计

在汽车开发中，系统设计阶段是一个非常多样化的过程。E/E（电气/电子）架构需要设计与电气世界相关的所有内容，从线束到单个ECUs的高级功能。考虑到这一点，很容易理解为什么架构设计是一个涉及许多具有不同技能组合的人员的过程，以及为什么车辆通常分为多个域，每个域都是一组相关的汽车组件。

2.1 Vector PREEvision

PREEvision是汽车行业及相关领域分布式嵌入式系统基于模型开发的首要工具。这个工程环境在一个集成的应用程序中支持整个技术开发流程。

PREEvision是E/E架构建模的一体化解决方案。它完全支持AUTOSAR方法，并可以通过ARXML和许多其他文件格式导入和导出数据，允许从其他软件迁移和/或集成到现有工作流程中。

图2.1显示了Vector宣传的PREEvision软件的各种功能，但本工作仅探索了其中三个组件：软件和硬件架构，以及通信层。

图2.1：Vector PREEvision软件的特点

2.2 系统和软件设计

图2.2显示了V模型的系统和软件设计阶段的流程。当然，并非所有步骤都是强制性的：从头开始，而不是从ARXML导入，并且只关注CAN网络。

图2.2:PREEvision中的系统和软件设计流程

2.2.1 软件设计

在此阶段，独立于物理模型对软件组件及其交互进行建模。软件工件可以分组为组合，并具有输入和输出端口，每个端口通常对应一个信号。一切都是通过图形方式完成的，将工件放置在画布上并绘制线条来连接它们。

图2.3至2.6显示了车辆外部灯光的简单软件模型。

图2.3：灯连接组成预驱逐模型

图2.4：灯光组成预驱逐模型

图2.5：前灯预驱模型

图2.6：尾灯预驱模型

图2.3显示了灯光域的一般组合。未完全建模Brakes SW Type和Gearbox SW Type，而Lights SW Type在图2.4中详细显示，其组件Front Lights SW Type在图 2.5 中，Rear Lights SW Type在图2.6中。

该符号代表传感器和/或执行器，

而它是一个软件组件。

传感器和执行器之间没有真正的区别，事实上，人工制品可以同时是两者。传感器通常只有发送器端口

而执行器只有接收器端口

此阶段的另一个重要步骤是数据类型创建。每个连接都必须分配一个数据元素，每个数据元素都需要一个数据类型。应用程序数据类型用于在逻辑级别区分不同类型的值；例如，可以定义Brake_Pedal_Position_DT和Accelerator_Pedal_Position_DT，并将它们映射到整数实现数据类型，但它们在逻辑级别将表示不同类型的数据。

数据类型也可以有计算方法，一种将值的内部表示转换为物理表示或反之亦然的方法。它们可以是文本的（只是每个可能值或值范围的描述）或数值的（应用于每个值或值范围的数学函数）。图2.7显示了转换方法的示例，具有分段数值转换和两个可能值范围的文本转换。

图2.7：转换方法示例

2.2.2 硬件设计、映射和路由

软件设计之后的下一步是对所有ECUs以及连接它们的网络进行建模，定义它们的类型和数量。此阶段与前一阶段类似，但涉及物理组件，而不是逻辑组件。最后，软件组件将映射到物理组件。这几乎从来不是1:1的映射，因为在实践中，同一个硬件组件可以承担多个软件组件的角色。软件和硬件组件的分离意味着更容易在ECUs之间移动功能，而无需从头开始建模所有内容。

图2.8显示了前面建模的外部灯光域的硬件模型，以及每个软件组件如何映射到ECU。

图2.8：外部灯光域的硬件模型，SW组件映射可见

建模完成后，可以运行信号路由器，它会自动为每个数据元素创建一个信号，并计算每个信号到达最终目的地必须经过的路径。

此时，可以将信号分组到PDU中，并将 PDU 分配给帧。在图2.9中，外部灯光信号（总共7位）已映射到3字节的PDU并插入到CAN帧中。

图2.9：CAN框架中的灯信号

在这一步中，还可以定义受E2E保护的PDU，并将它们代替普通PDU分配给帧。

2.2.3 ARXML导出

建模完成后，可以将结果导出到一个或多个ARXML文件，以便执行V模型的软件开发阶段。

在PREEvision中，这个过程只需点击几下，但重要的是要注意，对输出的检查很少；在许多情况下，在PREEvision中，可以插入矛盾的信息、省略所需的参数、提供不一致或不符合标准的值等，而软件不会发出警告，因此需要用户来验证模型的形式正确性。

2.3 软件开发与集成

V模型的这两个阶段通常外包给第三方；前者包括开发上一阶段建模的所有ECU软件，而后者包括物理硬件的配置和已开发软件的部署。

2.3.1 传统方法的问题

虽然这个过程对于批量生产来说已经很成熟，但将其应用于原型和小批量生产时会遇到一些问题：

·  成本非常高

·  获得最终结果需要很长时间

·  当需要进行小的更改时，灵活性不是很高

传统的开发阶段成本很高，原因有很多：首先，传统方法需要非常昂贵的软件和经过培训的人员来使用它，同时要遵循严格的编码规范。这对于批量生产来说是可行的，因为成本会分摊到数百万将要生产的单元上，但在开发原型时可能就不经济了。

然后是时间问题：将工作外包给承包商和分包商意味着完成开发过程需要更多的时间。同样，这对于生产来说是可以接受的，因为开发周期更长，但对于原型来说并不理想，因为时间通常很紧张。

最后，原型开发的本质是一个大问题：第一个原型很少是最终设计，因为设计师通常会在确定最终产品之前尝试各种概念和想法。这与传统的开发方法形成了对比，因为一个小的改变就意味着一个新的开发阶段，以及前面讨论的所有成本和时间问题。

另一方面，集成阶段与开发阶段紧密相关，通常第三方提供的物理硬件已经部署了软件，可以直接使用。同样，这意味着不重新开始开发阶段就无法进行某些更改。

总而言之，很明显，汽车原型行业将从软件开发和集成阶段的新方法中受益匪浅，我将在下一节中讨论。

03. V模型的替代方案

鉴于前面提到的传统V模型方法在应用于原型开发时存在的问题，有必要找到一种替代方案。将开发转移到内部可以解决时间和灵活性问题，但由于需要获取所需的软件和人力资源，可能会导致成本更高。

解决方案似乎是一个新的工作流程，专门为原型开发量身定制，但仍然与V模型系统设计阶段兼容。V模型的第一阶段保持不变，以便在原型演变为批量生产车辆的情况下可以重用该模型。

为了加快开发过程并使其更容易，可以自动化一些过程，特别是应用程序接口的生成。细节将在本章的其余部分解释，但该过程大致由以下步骤组成：

·  设计阶段后导出ARXML文件

·  处理ARXML并生成网络、ECU、消息、信号及其交互的描述

·  用C++开发ECU软件

·  将软件部署到开发板上

为了实现这个过程，需要两个主要组件：

·  一种处理ARXML文件、提取所有所需信息并将其以易于与C++代码集成的形式呈现的方法

·  一个C++库，提供通信层和应用层的接口

在以下各节中，将详细解释这两个组件，并提供一些代码片段。

3.1 Python ARXML解析器

为了处理ARXML文件，我决定走捷径，开发一个Python脚本。虽然考虑了其他方法，但Python被选为在速度和开发便利性之间的权衡。然而，该脚本保持非常简单，只有一个外部依赖：lxml。已经存在其他专门用于处理ARXML的Python模块，但发现它们不完整和/或文档不完善。此外，编写自己的解析器使我能够更好地理解ARXML格式及其特性。

清单3.1显示了Python解析器的前几行。traverse_arxml函数是ARXML遍历的核心。如前所述，ARXML 文件不像普通XML那样遍历，因此这个函数处理它。为了提高解析速度，它还采用了缓存机制，以便可以轻松检索之前访问过的树部分。相反，open_arxml函数打开ARXML文件并设置所有需要的变量。代码的其余部分涉及树的遍历和所有值的提取，这里不再列出。

清单3.1:Python ARXML解析器的第一行

当然，脚本并未涵盖 ARXML 导出的每个方面，只解析和提取必要的信息。特别是，提取了以下特征：

·  网络拓扑，即ECU及其连接

·  帧及其发送者和接收者的映射

·  信号及其内部到物理的转换方法

·  端到端保护配置和受保护的帧

首先，创建网络拓扑，通过映射所有ECU及其连接，找出每个端口发送的帧及其方向（出站或入站）。由于C++库目前只能处理CAN通信，因此只提取CAN网络。

对于每个帧，解析器提取ID和长度，了解是否使用扩展寻址、是否是CAN-FD帧以及需要何种E2E保护（如果有）。如果该帧表示周期性消息，还会提取时间和容差。

然后，处理每个帧中的信号；解析器提取消息中的位置、长度、字节顺序和初始值，并检查该值是有符号的还是无符号的。

然后提取信号的文本和数值内部到物理转换方法，以及每个范围的标签和/或系数。

最后，提取端到端保护配置，并将其与相应的帧相关联。

解析器接受一个或多个 ARXML 文件作为输入，默认情况下处理所有内容，但可以配置为仅处理某些ECU，或排除某些特定ECU。它的工作方式是，如果某些信息仅与未选中的ECU相关，则会从输出中省略；例如，这允许输出不是整个网络的通用输出，而是为单个ECU量身定制的输出。

最终结果包含两个文件，其名称在命令行上指定；一个包含所有ECU的映射，而另一个包含所有消息、信号和相关信息。这些文件的格式是一个包含所有提取信息的JSON转储的C字符串，它们可以直接与C++库链接。

选择JSON是因为它是应用程序之间数据交换的事实上的标准，保证了可移植性，并使将来更容易切换到不同的编程语言。

解析器已经用之前建模的组件进行了测试，还用一些批量生产的 ARXML 文件进行了测试，以确保它适用于实际应用。

3.2 C++库

为了简化软件开发，开发了一个C++库，旨在抽象CAN通信层，并提供对设计阶段定义的消息和信号的便捷访问。它被设计为具有尽可能少的依赖项（实际上甚至避免了boost库），并利用Linux的 SocketCAN来处理通信，利用nlohmann/json库将上一步导出的JSON转换为C++对象。实际上，该库唯一的硬要求是具有SocketCAN和工作的C++17编译器的Linux环境。

该库的主要特点是：

·  通过抽象CAN层的细节，简化消息的发送和接收

·  自动发送周期性消息，直接从ARXML获取正确的时间

·  通过回调函数在信号值更改时得到通知

·  对发送的消息进行E2E保护，并检查接收的消息是否有错误

该库由两个主要类组成：处理通信方面的CanLib和处理消息方面的CanMap。

3.2.1 CanMap

CanMap类负责处理消息和ECU的映射。它不直接被应用程序使用，而是向CanLib提供其功能（参见3.2.2节）。

首先，CanMap定义了nlohmann/json库将数据的JSON表示转换为C++内部结构所需的方法。

至于它所持有的数据，CanMap保留三个映射：

·  ECU映射，一个静态映射，包含每个ECU的入站和出站消息列表

·  信号映射，一个静态映射，包含每个信号的所有信息，如其长度和在消息中的位置

·  值映射，一个动态映射，用于所有非静态值，如信号的当前值、E2E保护计数器等

静态数据可以随时访问，但动态映射受到并发访问的保护。

getSignalCallback ()、setSignalCallback () 和 removeSignalCallback () 函数允许用户在信号值更改时通过回调函数得到通知。

清单3.2显示了CanMap类的头文件。

清单3.2: CanMap C++类的头文件

3.2.2 CanLib

CanLib类是库的核心，处理几乎所有其余功能。清单3.3显示了CanLib类的头文件。

首先，它抽象了通信层，提供 initSocket () 和 closeSocket () 函数来处理套接字的打开和关闭，以及 sendMsg () 和 getMsg () 函数来简化CAN消息的发送和接收。

清单3.3: CanLib C++类的头文件

handleCanMessage () 函数在接收消息后调用，检查它是否在容差范围内接收（如果消息是周期性的），并对于其中包含的每个信号，更新最后存储的值，通过转换方法计算物理值，并调用之前用 setSignalCallback () 注册的任何回调函数。

虽然sendMsg () 允许用户发送任意构造的消息，但sendSingleShotMsg () 发送一个已知的消息，给定其名称。库跟踪每个信号的“当前值”，允许用户通过setStoredInternalValue () 函数更改它。当发送已知消息时，它会根据其信号的存储值自动构造。这允许用户指示库通过startPeriodicSend () 函数发送周期性消息，并异步更新需要发送的值。

当test=false时，protectMessage () 函数将计数器和计算的CRC添加到消息中，或者当test=true时检查它们是否匹配。目前，只实现了奥迪在其现代平台上使用的特定E2E配置文件。

然后有一些静态函数来获取关于消息的信息，如isMessageExtended ()、isMessageCANFD () 和isMessagePeriodic ()。getMessageId ()和getMessageName () 分别从消息名称返回CAN ID，反之亦然，而getSignalNames () 返回消息中的信号名称列表。

通过getOutboundMessages () 和getInboundMessages () 函数访问ECU映射，它们分别返回ECU发送和接收的消息。

其他函数，如toPhysicalValue () 和getValueLabel ()，处理转换方法。

消息的周期性发送在ThreadHandler类中实现。当对消息调用startPeriodicSend () 时，它会检查是否已经有一个线程以相同的周期性发送消息，如果有，则将该消息添加到列表中；否则，它会创建一个新线程。线程遍历要发送的消息列表，一个接一个地发送，根据信号值的存储值构造它们。通过使用C++的计时机制，周期性的容差保持得非常严格。

3.3 其他组件

除了Python脚本和C++库，在这项工作中，我还开发了另外两个组件：一系列演示应用程序，以全面测试该库，以及一些CMake文件，以自动化和加速JSON生成和编译。

3.3.1 演示应用程序

在库的开发过程中编写了各种测试应用程序，随着库的发展，以测试越来越多的功能。

前两个应用程序只是为了测试发送和接收功能。然后，编写了一个同步测试，以确保两端的数据是一致的。这个程序随后扩展到支持CAN FD和E2E保护。当库扩展到支持周期性消息时，编写了一个周期性发送器测试应用程序。最后，实现了一个实际演示应用程序，将在第4节中讨论。

3.3.2 CMake文件

为了协调项目的所有部分，代码附带了一系列CMake文件。正如我将在3.4节中讨论的，CMake使为不同平台构建项目变得更加容易。

每个组件（Python解析器、C++库和演示应用程序）都有自己的CMake文件。Python脚本CMake的配置（以及整个项目的配置）需要输入ARXML文件的列表，并最终需要包含或排除的ECU列表。

另一方面，库的CMake接受一个配置标志来构建静态或动态库，还有一个目标是使用Doxygen构建文档，因为代码已经相应地进行了注释。

3.4 部署

既然已经开发了V模型软件开发阶段的替代方案，那么也需要集成阶段的替代方案。幸运的是，有一些开发板可以满足这一需求。本工作中使用的是恩智浦的S32G，如图3.1所示。它具有18个CAN、5个LIN、1个FlexRay和多个以太网端口，运行Linux并提供完整的开发工具链。

图3.1:S32G开发板图片

为了将软件部署到开发板上，第一步是为特定目标编译库和应用程序。幸运的是，制造商提供了一个完全支持CMake的工具链，因此编译前唯一需要的步骤是运行制造商提供的环境配置脚本。为了在相同环境中也运行Python解析器，第一次使用工具链时需要安装其依赖项。此时，配置和运行CMake将根据给定的配置自动为开发板构建库和应用程序。

要将软件上传到开发板，可以使用其以太网端口之一，在系统运行时通过SSH连接到它，或者将所有内容复制到其microSD卡。共享库也可以作为Yocto配方添加，并与操作系统一起构建。

在运行软件之前，需要配置CAN端口。库避免干扰CAN配置，而是透明地使用端口，将配置留给用户。可以使用ip命令行工具配置端口。例如，运行ip link set llcecan0 type can bitrate 500000 dbitrate 2000000 fd on将名为llcecan0的CAN端口配置为支持FD，在CAN模式下使用 500kbps 的比特率，在CAN FD的比特率切换阶段使用2Mbps的比特率。运行ip link set up llcecan0将启动具有给定配置的接口。此时，任何软件都可以使用llcecan0接口。

04. 实际演示

为了证明V模型替代方案的有效性，开发了一个实际应用程序。模拟了一辆量产车的前灯ECU，并用于驱动2020款奥迪A3的前大灯。这种特定的前大灯具有矩阵LED，需要特定的信号才能开启。

图4.1:2020奥迪A3的前视图

不幸的是，我不能在这里展示，但我可以访问前灯网络的CAN数据库。它不是ARXML格式，因此需要转换，但除此之外，它与我之前使用的测试ARXML没有区别。

该网络上的许多CAN消息使用E2E保护，并且如果没有收到特定的周期性消息，前灯会自行关闭。所有这些方面使前灯ECU成为全面测试库所有主要方面的完美候选者。

前灯演示应用程序有一个菜单，可以从中选择所需的选项。首先要做的是启用CAN消息的周期性发送，以便前灯可以退出其错误状态（由于缺少特定消息）并打开。然后，需要断言钥匙状态，否则灯将始终保持关闭。此时，可以驱动前灯的各个组件：日间行车灯、位置灯、近光灯、矩阵LED远光灯和转向灯。

该演示通过仅发送完全控制前灯所需的消息来工作，而不是真实车辆网络中通常存在的所有消息。大部分信号以其默认值发送，而其中一些需要设置为特定值才能打开前灯。菜单选项使用setStoredInternalValue () 库函数更改特定信号的存储值，而发送周期性消息的线程处理其余部分。

这个实际实现还提供了关于开发板能力的一些有用见解。尽管本工作的范围只是证明以这种方式驱动批量生产的组件是可行的，而不太关注性能，但还是监测了开发板的CPU负载和周期性消息与标称时间的偏差。这些指标非常有用，因为它们允许我优化和改进库（最后一次迭代使用的CPU功率几乎是第一次的百分之一）。需要注意的是，这两个参数没有经过严格测量，因为这不是本工作的主要范围，但我可以报告，运行前灯演示时，开发板的CPU负载保持在2%到3%之间，周期性信号的时间与标称值的偏差从未超过2毫秒。然而，在更高的负载下，开始出现需要进一步研究的时间尖峰。

05. 结论与未来发展

在前面的章节中，我定义了一种新的软件开发和集成方法，并建立了一个被证明适用于实际场景的开发框架。S32G开发板也被证明完全有能力支持这样的应用程序。通过一些改进，这个框架可以用于公司未来的项目，如新型展示车或原型车。到今天为止，该库足够稳定，可以用于演示，但需要经过彻底验证才能用于小批量生产车辆。由于能够控制现成组件，车辆可以配备来自不同平台的组件，并通过在开发板上实现的中央网关使所有组件相互通信。

至于未来的发展，C++库将受益的主要改进是：支持其他通信网络，如LIN和以太网；将 E2E 支持扩展到更多配置文件；更自动化的消息接收方法，或许与SocketCAN在内核空间过滤消息的能力相结合。向面向服务的架构扩展也将非常有趣，或许可以使用SOME/IP。相反，Python脚本需要根据更多实际设计和不同工具生成的ARXML文件进行验证。