零、可能会用到的基础知识

SWC-Runnable-Task

上图选自 [AUTOSAR Layered Software Architecture] R21-11

• SWC：SoftWare Component
• Runnable：顾名思义，可运行实体，一个 SWC 对应任意多个 Runnable。
• Task：任务，是操作系统的概念。相当于常说的进程，一个任务执行中可以执行任意多个 Runnable。

PduR

• PDU：Protocol Data Unit（协议数据单元），一个比较常见的概念，可以自行某度，或者理解为数据包。
• I-PDU：Interaction Layer PDU，因为 COM 在 ISO 标准中被称为 Interaction Layer，因此 COM 中的 PDU 被称为 I-PDU。
• Message：常说的 Message 在 COM 中等同于 Signal，但是在 DBC 中等同于I-PDU，相当于一条报文。这点是易错的。
• PduR：Pdu Router，COM 向下交互的主要对象。顾名思义，是一个路由 PDU 的模块。

Com 与 ComM

• Com：就是我们研究的模块，有时候写 COM 有时候写 Com，都是相同的。主要就是来通信的（收发信号，在 COM 中组包为 I-PDU 交付给 PduR 路由到目标总线协议的处理模块）。但是有时候也会用来泛指所有的通信模块，例如，车上所有参与通信的相关模块，也会被称为 Communication 模块，即 Com，指车上实现通信的所有模块的总和。我们说 Com 模块或者 COM 模块，一般说的是前者，即我们本文研究的模块。而不是实现通信的所有模块。
• ComM：就是特指 Communication Management，这里的 Com 指的是所有底层总线通信模块，ComM 并不管理通信的所有模块，实现网络管理也不需要管理所有模块，只需要管理对总线的抽象即可。ComM 通过管理底层总线协议的抽象，实现相关的各个协议的总线网络管理功能。

一、五个词语获取对 COM 模块的基本理解

1. Signal。AUTOSAR 最上层 APPL（应用层，每个应用程序为 SWC，即 SoftWare Component，通常会为每个 SWC 配置一个任务或者进程来运行）。SWC 可以实现一些软件功能，例如，手机靠近，车内有 ECU（Electronic Control Unit 电子控制单元，理解为一个零部件中有一个小小的而且非常简单的电脑，可以通过这个电脑来控制这个零部件）读取到手机的蓝牙信号，ECU 把读取到的蓝牙的相关数据传输给 车控系统 （汽车控制系统，理解为汽车的大脑，汽车的操作系统，可以协调车身上各个零部件 ECU 的运行，给各个 ECU 发指令，或者从 ECU 中得到信息），系统得到信息后经过底层的一些处理（相当于电脑的 TCP\IP 协议栈对网络报文的处理），然后传递给 SWC。此时 SWC 可以进行一些计算判断是否是车主来了，如果是就给他开车门。这个过程中，SWC 需要用到一些关键数据，比如说蓝牙传来的认证数据长度等等，这个数据在 AUTOSAR RTE 以及 AUTOSAR APPL 中，就是一个 Signal。COM 在 CAN 通信协议栈的最顶层，向上层与 RTE 交互，因此 COM 层需要向上层提供 Signal
2. PDU。一个一个信号发效率太低了，类比TCP\IP协议栈的组包，COM 层就把很多信号放到了一个 PDU 中（Protocol Data Unit，理解为一个数据包，或者说一个数组或者结构体，里面放很多数据） 。COM 层向下层与 PduR 交互，PduR 负责把报文路由给相应的模块。AUTOSAR 中包含很多总线协议，这是为了满足不同 ECU 的总线需求以及成本需求。信号可能来自多个不同的 ECU，有的 ECU 使用 Lin 总线，有的使用 Can 总线，有的使用 FlexRay 等等，PduR 的责任就是把 COM 组的包，路由给目的总线的处理模块。由相应的处理模块去发送。接收就是从相应的总线模块路由给上层。同样 COM 只负责解包 PDU 为 RTE 提供 Signal，还有一些其他模块比如网络管理模块（管理总线网络，总线处于不同的模式时有不同的功耗，所以需要网络管理，平衡功耗和需求）也需要收发报文，有时候也会路由给他们。
3. 数据控制。类比 TCP\IP 协议栈，有时候收到无效的数据需要丢弃，或者需要看看期待接收的报文有没有在规定时间到达，或者包的序列号是不是我想要的，是不是收到了过期或者乱序的包，或者我希望我按时间间隔发送或接收消息，来确认我和其他 ECU 都在正常工作等等。COM 也需要实现这些功能，以保证向上层提供灵活的数据发送功能和提供有效及时的数据。
4. 通知。要是出错了怎么办，你不说，我不说，大家谁也不知道，就当是无事发生好了？那可不行，要是有数据应该发出去，没发出去；或者应该收到，但是没收到；数据出错了；发来了无效的数据，是不是 ECU 故障了，等等。COM 需要及时向上层通知，确保系统使用者以及管理者来做决定该怎么办。
5. 信号网关。有些 ECU 需要发给其他 ECU 信息，但是他俩还不在一个总线，这该咋办？此时我们的 COM 就充当了一个网关，因为我可以让信息通过 PduR 发送到想要去的总线处理模块，所以我可以当网关。例如，CAN 总线发来信号，这个信号需要路由到 Lin 总线，那我放到一个可以路由到 LinTp 的 PDU 里，再交给 PduR，就完成了对数据的路由。

二、架构观察，COM 是个什么角色？

为了严谨科学，也为了保护原作者版权，事先声明，本节会用到 autosar 官方文档的部分图片。

文档名称：AUTOSAR Layered Software Architecture，链接

版本：R21-11

选自上述文档的 Page 102。

这个图和上面所说的内容就对应起来了。也证明了 PduR 存在的意义，他不是单独为 Com 服务的，而且有了 PduR 的抽象，方便可以对路由路径修改。

为什么说 ComM 不需要管理所有的模块，如图橙色箭头所示，只需要管理总线协议，就可以实现对相关总线的使能、监控。 网络管理和业务所需的报文数据是分开的，因此如果通过底层通信协议之上的业务模块来网络管理的话，例如 Com，就会导致业务数据和网络管理的数据耦合都需要从底层总线经由 PduR 到达 Com，在交给 ComM，产生了耦合。很有可能存在紧急业务数据，例如弹出安全气囊的信号，因为网络管理报文的收发、处理导致带来延迟，哪怕可能1、2ms，对驾驶者、乘客而言肯定是不希望看到的情况。网络管理和业务数据分开，属于垂直方向的解耦（不是专业术语，重点会意就行） 。

Com 涉及到的总线协议理论上应该是包括 CAN、CANFD、TP（TP 总线具体是什么有待研究，COM 官方文档中提及到的大报文使用的就是 TP 总线）（这里不确定全不全，有待补充，欢迎讨论，交流，希望懂的大佬不吝赐教）。实际 COM 官方文档中提到的只有 CAN 和 TP。关于总线协议可以看这篇文章 CAN\CANFD\FlexRay\LIN 一文深度解析常见通信协议。

三、COM 入微，你说的这个 COM 他漂亮吗？

他不是漂不漂亮的问题，他真的是那种，很少见的那种……（稍微皮一下）

这里提到的不明白的名词，直接去这篇文章里 ctrl + F，【AUTOSAR-CP-CAN-2】AUTOSAR COM。

本节 Autosar 官方文档的部分图片引用自文档 Specification Of Communication。

1、Com 发送流程分析分解

1. SWC 调用 RTE 提供的 Send_Signal、Send_SignalGroup 接口
2. Send_Signal 会检查信号是否配置了开启更新位，如果配置了，就会设置更新位为 1（更新位也在 PDU 中，不是信号数据的一部分，但是该信号的更新位和该信号在同一 PDU 中，任意空位置都可以用来设置某个信号的更新位）
3. 把信号转换字节序（CPU序到总线网络序）
4. 拷贝到 PDU 中
5. Signal Transfer Properties：如果该信号的发送属性为 Trigger，他期待立即发送，那么就会触发信号所在 PDU 的发送。
6. Transmission Mode Selection：触发发送时，使用该信号的值作为输入，根据 Filter 算法，算出一个结果，True 或者 False，True 就会使用该 I-PDU 的 TxModeTrue 发送模式，否则使用 TxModeFalse 发送模式（我们可以为 I-PDU 事先配置两个发送模式，即 TxModeTrue 和 TxModeFalse，加上 Filter 我们就实现了对不同的信号值可以选择不同的发送模式的功能）
7. PduR_ComTransmit + Transmission Deadline Monitoring：如果触发发送，就会开启 TxDM，TxDM 在接收到发送确认时就会取消，否则超时就表明没有成功发送出去，就会引起对上层的通知，这个通知是提前配置好的接口，我们直接调用即可。
8. Minimum Delay Time + Notification：如果成功发送，就会设置 MDT，表示该报文在接下来 MDT 时间内，不可以再发送。并调用提前配置的通知接口，进行通知。
9. MainFunctionTx：如果没有触发直接发送，触发了混合或者周期发送，或者触发了直接发送但是还需要重复（repetition）再发几次，那么这些发送会在 MainFunctionTx 中处理，只要发送，就还会涉及到上述步骤2到步骤7。

2、Com 接收流程分析分解

1. PduR 调用 RxIndication 传入 PduId 转发来自 CanIf 或者 CanTP 的 PDU 包，拷贝到 Com
2. 重置 PDU 的 Rx DM
3. 检查更新位，如果配置了更新位，且未设置，则丢弃 PDU
4. 通过则逐个检查 PDU 中的信号，每个信号都会经历下面 【5 - 8】
5. 对信号执行字节序转换以及符号扩展
6. 检查信号是否为提前配置好的无效数据，会有配置好的动作，NOTIFY 或者 REPLACE，顾名思义，前者为通知，后者为替换数据为指定数据
7. 接收过滤，有几种过滤算法，关于过滤算法，【AUTOSAR-CP-CAN-2】AUTOSAR COM 的 3.1.4。过滤算法根据输入的值计算出 True\False，来判断是否让这个信号通过。
8. 通过则重置对信号的 Rx DM
9. 从 COM PDU 拷贝到对应的 Signal 的区域
10. Com 根据 PDU 的处理方式 IMMEDIATE，则为 PDU 立即执行通知，调用提前配置好的通知函数，通知 RTE（中断）；DEFERRED，则设置标志位，下次 MainfunctionRx 会检查 PDU 标志位，如果设置了标志位，会进行通知（轮询）。
11. 回到 【4】，直到遍历完所有信号

3、Com 信号网关分析分解

下面英文的大意：这里信号网关路由信号到 Tx 方向的 PDU 时，需要字节序转换和符号扩展，以便在 TMS （发送模式选择）时的输入是正确的。在接收端，字节序转换仅在接收总线的字节序和当前 CPU 序不同时有必要；在发送端，字节序转换仅在接收总线的字节序和当前发送总线的字节序不同时才有必要。

1. PduR 调用 RxIndication 传入 PduId 转发来自 CanIf 或者 CanTP 的 PDU 包，拷贝到 Com
2. 重置 PDU 的 Rx DM
3. 检查更新位，如果配置了更新位，且未设置，则丢弃 PDU
4. 通过则逐个检查 PDU 中的信号，每个信号都会经历下面 【5 - 8】
5. 对信号执行字节序转换以及符号扩展
6. 信号是否配置了进行路由，是则进行路由，执行下一步，未配置路由则执行 【8】
7. 路由到发送方向的 PDU，设置更新位，字节序转换以及符号扩展，之后发送流程同上述发送过程 【6 - 9】，结束后执行 【8】
8. 之后和上述接收过程 【6 - 10】相同
9. 回到 4，直到遍历完所有信号

四、什么，还得让我学会配置？

本节 Autosar 官方文档的部分图片引用自文档 Specification Of Communication。

图片注解：

• upper Multiplicity = 实例个数上限
• lower Multiplicity = 实例个数下限
• 图片上每个方块中带有下划线黑色字体的含义，变量名 : 变量类型
• Gw： Gateway 信号网关的相关容器
• I-PDU：已有解释
• Signal、Signal Group： 多个 Signal 可以组成一个 Signal Group，一个 I-PDU 包含任意个 Signal、Signal Group
• Ref：引用，可以理解为指针

配置解释：

• 整个 COM 的全部配置放在一个大结构体中，该结构体变量名为 Com，结构体类型为 EcucModuleDef
• Com 包含两个容器：ComGeneral （一些通用或者一般的参数）与 ComConfig （Com 中各个子容器及其参数）
• TxIPdu 下有 ComTxModeTrue 和 ComTxModeFalse，这里就是 TMS 发送模式选择，根据 Filter 得到 True 或 False 来选择不同的发送模式
• 各个模块在 【AUTOSAR-CP-CAN-2】AUTOSAR COM 基本都有覆盖，不理解可以再去找到相应功能，然后打开 Specification Of Communication 第十章的配置部分第一节，查看每个参数的具体含义。

五、撒日朗，你劈我 COM 是吧？—— 还得数据映射

正如上文所说，Com 之上使用 SignalId，而 Com 之下使用 PduId，这两个如何对应？

• 不是随意组合，一般是由 DBC 或者 ARXML 定义的。关于 DBC，这篇文章。【AUTOSAR-CP-CAN-1】DataBase for Can——深入理解 DBC 通信矩阵 。
• 更多详细资料有待学习 AUTOSAR System Template

持续更新中，敬请期待，欢迎交流