【技术进阶】深入AUTOSAR BSW：Com配置的6个核心问题剖析

最新推荐文章于 2025-02-08 10:14:50 发布

汽车电子工具智慧库

最新推荐文章于 2025-02-08 10:14:50 发布

阅读量1.5k

点赞数 30

文章标签：汽车 Autosar 通信 Com

本文链接：https://blog.csdn.net/2201_75514516/article/details/144578618

版权

往期推荐

配置AUTOSAR BSW中的Com过程中经常遇到的几个问题：

往期推荐

在这里总结下

配置AUTOSAR BSW中的Com过程中经常遇到的几个问题：

- 如何使用通信矩阵定义通信消息；
- 如何配置 BSW 通信模块，以便发送/接收特定消息；
- 帧、PDU 和信号之间的映射如何工作；
- RTE 如何与 Com 和 A-SWC 进行接口；
- A-SWC 如何与下层交换消息；
- 选择的通信协议是 CAN，以下所有信息将符合 AUTOSAR 关于 CAN 通信的规范。

以下通过ISOLAR-AB 及选择 通信协议 CAN为例进行相关阐述。

配置生成

ISOLAR-AB 允许导入 DBC 文件。DBC 代表 DataBase CAN，即包含以下信息的特定格式：

- 通信系统中的通信节点（ECUs）；
- 消息的源、目标以及包含的信息；
- 消息与信号之间的映射；
- DBC 默认消息被视为 CAN 帧。

导入 DBC 后，可以使用嵌入的 confGen 工具生成 BSW 配置。

DBC Importer允许选择要在 ISOLAR 项目中导入的通信节点（即 ECU）和相关消息。如果导入过程成功，在 ISOLAR 的图形视图下的system中，可以浏览消息、信号和 ECUs。

配置生成器( confGen）在命令面板中由符号 E 表示。它允许选择要使用的 BSW 生成器和要生成的 ECU。生成的配置有时是不完整的，需要根据特定的用例进行更改。

通信实体之间的映射

DBC 文件概览

DBC 文件具有独特的语法和语义来存储信息。关键字以粗体显示在括号中：

- 版本 (VERSION)
- 新符号 (NS_): 定义文件中使用的所有符号。需要注意的是：在 NS 中定义的符号应是实际在后续中使用的符号。如果定义了一个符号但未被使用，DBC 导入器可能会显示“DBC 文件无效”的错误信息。
- 比特定时 (BS_): 非常少见。在我们的情况下，符号仅被定义而没有参数。
- 通信节点 (BU_): 通信中的 ECU。
- 消息 (BO_): 组成通信的消息。定义新消息可能需要在 MCAL 中进行定义：在这种情况下，需要使用 MCAL 邮箱。
- 信号 (SG_): 每个消息应包含至少一个信号。
- 信号的属性、注释和类型定义；
- 通用/全局属性、定义、类型、值和信号及消息的类别；

CAN 消息描述

基本上，CAN 消息包含两个部分：

- CAN 标识符或 CANId；
- 负载；

实际上，CAN 有两个不同的版本。这影响消息的解码。特别是，影响字段是 CAN 标识符，可以是 11 位（常规类型）或 29 位（扩展类型）。而负载长度最多为 64 位。因此，CAN 消息的最大长度为 96 位或 12 字节。

CAN 消息的强制属性包括以下内容，以及标识符：

- 消息长度（通常以字节为单位）；
- 消息的源；
- 消息的目标；

从 CAN 消息到 DBC 文件，考虑以下消息（扩展 CAN）：

CAN 标识符由 32 位中最重要的 29 位表示（较不重要的位在右侧）。因此，CAN 标识符的范围可以是 0x0 到 0x1FFFFFFF（536,870,911）。

消息的其余部分包含信号。信号描述应包含：

- 信号名称；
- 信号起始位（起始点是负载左侧的第一个位）；
- 信号编码：
  - 0 表示 BIG ENDIAN（编码从最重要的位/字节开始，按位置顺序）；
  - 1 表示 LITTLE ENDIAN（编码从较不重要的位/字节开始，按位置顺序）；
- 数据符号（有符号或无符号）；
- 信号值计算（最常见的是 LINEAR，对于布尔值提供 1 和 0）；
- 信号下限和上限；
- 值的测量单位；
- 信号的目标节点。

有关 DBC 文件中消息及相关信号描述的详细信息，可查看相关文档进行详细系统学习，这里暂不做过多赘述。

在应用层和RTE层的信号管理

通常，在应用层，通信通过虚拟功能总线（Virtual Functional Bus）实现，这依赖于端口、接口和数据元素的定义。当一个实际系统被配置时，如果两个应用软件组件被映射到不同的ECU上，消息发送将通过总线系统进行。消息中包含的数据仍然由软件组件端口读取或写入，但它们会经过整个AUTOSAR stack。因此，一个应用软件组件需要以下元素：

1. 定义一个端口，并关联相关的端口接口和数据元素（这些元素应符合信号的性质）。
2. 在这个阶段，Tx和Rx信号没有区别，因此组件可以包含Tx和Rx端口的定义。
3. 定义一个可运行单元（runnable）和一个相关函数以使用该端口。
4. 定义一个事件以指定可运行单元与RTE的交互。

在分层架构中，信号转换的第一个步骤是在RTE和Com之间的接口中。为了生成BSW和ASW之间的RTE接口，需要从系统描述中提取出一个特定于ECU的实现。这就是ECU提取（ECU Extract）。

主要来说，系统描述包含了应用软件组件在ECU中的映射，以及系统数据映射，其中应用软件组件的端口接口与所有信号信息（如系统视图中所述）、PDU和帧（定义原始消息）相关联。请参见以下图片：

注意：COM模块（BSW）实际上将PDU和信号定义为配置容器（对象）。也就是应用层无法知晓有关单个信号的所有配置和校准方面。在Com中，主要的配置容器有：1）Com/ConfigSet/comIPdus，其中包含对2）Com/ConfigSet/ComSignal的引用。后者仍然包含对信号映射的引用，信号映射是根据系统模板（EcuC模块描述）定义的。

在BSW层的信号和消息管理

AUTOSAR BSW层包含通信栈，这些栈在服务层、ECU抽象层和微控制器抽象层之间垂直分布。此外，系统服务中还有一个通信管理器模块。所有这些BSW模块需要进行配置，以便在总线系统上允许信息交换，并将信息转发到应用层。对于ComM，configSet直接生成一个应用服务组件。

在通信服务中，主要与RTE直接“连接”的模块是Com和Dcm。基本方面包括BSW模块之间的依赖关系以及它们与BSW管理器之间的依赖关系。

通信服务可能会强烈依赖于网络管理。例如，部分网络管理将需要配置比经典通信更多的模块。LIN网络的管理也是如此。有关引用依赖关系的快速视图见下文小节。

Com模块说明如下

ComPdu的描述如下：

ComPduIdRef：引用EcuC中的Pdu结构定义（EcuC/ConfigSet/Pdu）。这类似于一个全局定义，可以被Com栈中的所有其他模块继承来描述Pdu。

ComIPduGroupRef：引用IPduGroup。这是一个对Com/ConfigSet的容器引用。Pdu组实际上用于部分网络管理，在此范围内非常有用。

ComIPduSignalGroupRef：引用Com/ConfigSet/ComSignalGroup。如果ComIPdu的这个引用不为空（不同于NULL），则它对ComIPduSignal的引用将为空。在这种情况下，ComNotification将为每个配置为I-PDU且引用设置为信号组的Com提供通知。

ComIPduSignalRef：引用当前Pdu中的信号。每个PDU可以包含多个信号。这些信号在Com/ConfigSet/ComSignal中进行描述。

ComSignal配置容器在应用层与BSW之间的信息交换中非常有趣。信号描述将类似如下：

参数ComNotification可以设置为生成回调（callback）。该回调将提供通信状态的信息。ComNotification可以为以下对象配置：

发送（Tx）端

- 信号；
- 信号组；
- I-PDUs。

接收（Rx）端

- 信号；
- 信号组；
- I-PDUs。

发送端的回调

- 声明：Com_Cbk.h
- 定义：用户范围
- 调用：void Com_Cfg::Com_TxNotify_<SignalName>(void)

接收端的回调

- 声明：
  - Com_Cbk.h：声明在ComNotification描述中配置的回调；
  - Rte_Cbk.h：声明带有静态名称的回调，形式为Rte_Cbk_<SignalName>。
- 定义：根据Rte_Cbk.h中的声明，由RTA-RTE生成器在Rte.c中完成。
- 调用：
  - 在实现ComNotification中配置的原型声明的用户函数中调用（用户范围 - 当应用软件组件绕过RTE调用回调时非常有用）。
  - 如果回调名称与RTE生成的相同，则实现是通用的。
  - 静态函数指针由RTA-BSW生成器自动分配，位于结构类型Com_Prv_xTxSigCfg_tst中（Com_Cfg.c资源）。

ComM 说明

通信管理器（Com Manager）是一个系统服务模块，主要负责通信范围内的模式管理。它是部分网络管理的关键模块。实际上，部分网络支持通过配置参数在ComM中实现。容器Pnc（部分网络集群 - 不要与RTA-SUM_PNC = 部分网络协调器混淆！）描述了与部分网络相关的所有配置方面。

需要注意的是，部分网络在更高层次上（包括服务层）是纯粹“逻辑”的。在服务层，部分网络的上下文只是以下内容的集合：

1. 在某个信道上通信的ECU；
2. 该信道上的PDU

实际上，部分网络是以下两者之间的映射：

1. 一个ECU可以通信的CAN信道；
2. 在特定时刻可以在该信道上运行的已启用/禁用的PDU。

启用部分网络代表着允许在该信道上传输/接收映射的PDU组。此映射存在于通信系统的每个ECU中。启用和禁用模式需要模式管理器的服务，例如ComM、BswM、EcuM等。

因此，支持部分网络管理需要配置部分网络集群以及网络管理模块的配置，否则将无法成功生成BSW代码。以下图表展示了ComM与其他BSW模式之间的主要依赖关系：

部分网络集群作为一个有限状态机（Finite State Machine）工作，以管理通信模式。每个部分网络集群是一个独立的有限状态机，服务于特定的ComM用户（ComMUser）。ComM用户是用于跟踪ECU分区内通信的对象（在实际RIP中未使用，但可用于安全概念）。如果部分网络集群被启用，系统通信中的节点将使用NM帧交换信息，主要包括请求和释放。每个部分网络集群将在NM中为自己使用一个专用的位位置。

mailbox

DBC只是用于通信的系统描述，这种描述仅足够用于生成服务层的配置。请记住，消息最初是物理信息。要将其转换为逻辑信息，消息必须在MCAL（驱动程序）和CanIf（接口）中定义。借助mailbox的功能，这种定义才得以实现。mailbox是在MCAL中定义的，必须在ISOLAR项目的CanIf配置中体现。

mailbox是容器，可以将多个消息分组。分组是通过CAN消息标识符实现的：如果CAN消息标识符通过了适合特定mailbox的过滤值，那么它将被分组到同一个mailbox中。当然，过滤值的定义应与CAN的类型匹配：扩展版应为29位，普通版为11位。每个mailbox可以包含一个或多个消息。

mailbox可以通过TresOS 16工具进行配置。该工具允许以图形方式定义掩码，而不是手动处理掩码。请记住，邮箱是硬件对象，因此受目标系统硬件资源的限制。有关这些限制的所有信息应从目标系统的用户手册中获取。Tresos可能需要为每种目标系统使用专用编译器。

关于ISOLAR：mailbox的配置也必须在ISOLAR项目中体现。这是因为其他模块会使用多个引用，例如EAL（ECU抽象层）中的接口模块。如果查看ISOLAR中Can的配置描述，就会注意到以下信息：