做AUTOSAR通信栈（COM）调试的工程师，几乎都遇到过这种场景：矩阵设计文档里明明写着某个报文是10ms周期，拉上CANoe一看，实际发送间隔却忽长忽短，甚至总线负载被冲得很高；或者应用层明明调用了Com_SendSignal，报文却一直不出去。这类问题十有八九出在COM模块的Transmission Mode（传输模式）和Transfer Property（传输属性）这两个配置上。一个管PDU层，一个管信号层，分开看都不难，组合起来却很容易配出意想不到的效果。这篇文章我结合这几年在AUTOSAR COM配置和实车调试中的经验，把这两个参数的逻辑、典型场景和踩坑记录完整梳理一遍，新入行的朋友可以当实战参考，老手也可以对照排查手头的问题。
1. 先理清COM在通信栈里的位置
1.1 COM模块到底管哪一段
AUTOSAR的分层模型里，应用软件组件（SWC）并不直接操作总线，而是通过RTE调用COM提供的接口。数据流大概是这样的：SWC把信号值通过RTE传给COM，COM完成信号的打包、字节序转换、符号扩展等处理后，把数据放进对应的I-PDU缓冲区，再通过PDU Router转发给CanIf、CanDrv等接口层，最终由CAN控制器发出。接收方向的流程相反，总线来的原始报文会一路送到COM，COM解包后把信号值放好，等待应用层通过RTE读取。
所以COM的定位是“信号级处理模块”，它负责两件核心的事：
- 信号和PDU之间的打包/解包，包括位序、字节序、符号扩展、无效化处理。
- 控制PDU的发送时机，也就是所谓的传输模式和传输属性。
很多人刚接触AUTOSAR时会纠结，为什么不能直接把DBC导入就直接用？因为DBC描述的是CAN矩阵，而AUTOSAR COM不仅要做报文格式转换，还要负责应用层看到的信号接口、发送调度、超时监控、路由网关等逻辑。传输模式和传输属性，就是这套调度逻辑里最关键的两个旋钮。
1.2 发送行为是“两级控制”配合的结果
总线上的最小传输单元是PDU，一个PDU里往往塞了好几个信号。比如一个车身控制器报文，可能同时包含门锁状态、车窗位置、报警计数、校验位等多个信号。
PDU什么时候发出去，由PDU级参数决定，这就是Transmission Mode。
信号写入时能不能“推一把”PDU发送，由信号级参数决定，这就是Transfer Property。
打一个不太严谨但很好懂的比方：PDU就是一班发往总线的班车，Transmission Mode决定这辆车是定时发车、等客满发车还是随时响应调度；而Transfer Property决定某个乘客（信号）上车时，有没有权利对司机喊一句“快发车”。两者必须配合，缺一不可。
很多配置错误就是只调了其中一级，比如把信号设成Triggered，却忘了PDU还是Periodic模式，结果不管信号怎么写，报文永远等周期到了才发；反过来，把PDU设成Direct，但所有信号都是Pending，那么什么触发源都没有，报文可能一帧都发不出去。下面我把这两级的细节拆开讲。
2. Transmission Mode：PDU的发送时机由谁定
2.1 四种基础传输模式的语义
AUTOSAR COM里，传输模式可以归纳为Direct、Periodic、Mixed、None四种，不同工具里名称会略有差异，但语义是统一的。我整理了一个速查表：
| 模式 | 核心行为 | 典型场景 |
|---|---|---|
| Direct | 有触发事件立即发送，无周期定时器 | 高优先级事件报文，比如碰撞信号、紧急故障码 |
| Periodic | 按固定周期无条件发送 | 常规周期状态报文，比如转速、车速、温度 |
| Mixed | 窗口内可被事件触发立即发送；窗口结束无论如何补发一帧 | 既要求周期新鲜度又要求事件实时性的报文 |
| None | 不主动调度，只能靠外部显式触发发送 | 网关转发的纯接收PDU、诊断类报文 |
Direct模式适合那些“要么不发，发就是有大事”的信号。这个模式下，PDU内部没有周期定时器，发送完全依赖信号触发，或者应用调用Com_TriggerTransmission这类显式触发函数。好处是响应快，坏处是如果一直没有信号更新，报文就永远不发，接收端如果要靠报文新鲜度做监控，很容易超时报错。
Periodic模式是最常见的，也是很多工程师默认认为“所有通信报文都该这么配”的模式。它简单可靠，每个周期不管数据有没有变化，都会向总线上发一帧。这样做对接收端非常友好，因为可以用周期报文的到达与否做链路健康检查。缺点是总线负载是恒定的，哪怕信号值几十年不变，也会按固定频率占用总线。
Mixed模式是两者的折中。它可以配置一个时间窗口，在这个窗口内，如果某个信号的更新满足触发条件，PDU立即发送；如果整个窗口都没有任何触发，窗口结束时照样补发一帧。这样既保证了“有事立即报”，又保证了“没事也不会沉默太久”。
None模式在普通ECU的发送类报文里用得不多，但网关路由场景很常见。某个PDU从一条总线进来，原封不动或者稍作处理后转发到另一条总线，本地应用不参与发送决策，这时候如果把COM当作发送端来调度，反而会打乱原有节奏。
2.2 Mixed模式的“时间窗口”到底怎么理解
Mixed模式里最容易误解的是ComTxModeTimePeriod这个参数，很多人以为它就是“周期”，其实在Mixed模式下它的含义更接近“最长沉默时间上限”。
我拿实际项目举个例。某个PDU配置为Mixed模式，ComTxModeTimePeriod = 10ms。它的运行逻辑是：从计时起点开始，10ms内如果某个具备触发能力的信号被更新，PDU立刻发送，并重新开始计时；如果这10ms内什么触发都没发生，那么10ms结束时强制发一帧，同时重新开始计时。
所以从总线上观察，最坏情况下我们也能保证每10ms至少有一帧，但实际发送间隔可能是2ms、7ms、10ms不等。如果把ComTxModeTimePeriod改大，比如100ms，那么总线上可能长时间一帧都没有，直到某个事件信号被置位才突然发一帧。这个行为对接收端的影响必须提前评估，否则很容易出现对方报“报文超时”。
另外要提醒的是，AUTOSAR规范在设计上还引入了“发送条件”的概念。严格来说，PDU的发送行为取决于“条件满足”与“条件不满足”两套分支，分别可以配True模式和False模式，混合模式的底层本质就是“条件满足时直接发”“条件不满足时周期发”。工具里我们填的ComTxModeTimePeriod、ComTxModeTrue/False参数，最终会映射到生成代码里的发送控制结构。理解这一点之后，看到AUTOSAR标准里那些复杂的模式描述就不会懵了。
2.3 重复发送机制也不能忽略
除了上面四种模式，还有一个经常和Transmission Mode搭在一起用的机制，叫重复发送。某些事件型报文在首次触发后，会连续发送好几帧，帧与帧之间按固定间隔隔开。为什么需要重复发送？主要是为了提高接收概率，尤其是系统刚唤醒、总线调度还不稳定的阶段，多给几帧就等于多给几次重试机会。唤醒确认、模式切换确认这类场景几乎都会用到。
重复发送次数和重复发送周期一般在PDU级配置。需要注意，重复发送会额外占用总线带宽，次数不宜设得太大。我曾经见过有人把一个故障码报文的重复次数设为10次，触发一次就连续10帧，整条总线在故障瞬间直接被占满，其他高优先级报文全部延迟。这种事在实车上排查起来非常痛苦，因为故障码不是每次触发都能复现，总线波形一抓就是一堆重叠帧。
3. Transfer Property：信号怎么推动PDU发送
3.1 Pending和Triggered的差别
Transfer Property在信号级配置，AUTOSAR COM里常见的有四种：Pending、Triggered、Triggered On Change、Triggered On Change With Repetition。它们决定了应用层调用Com_SendSignal写入信号值时，COM要如何看待这次写入。
先看最基础的两种：
Pending（待处理）：信号值被写入缓冲区，但不会触发PDU发送，相当于“先记在账上，等统一结算”。这类信号适合做辅助信息，它们的数据会被放在PDU缓冲区里，等到PDU因为别的原因被发送时一起带出去。
Triggered（触发）：只要应用调用Com_SendSignal写入该信号，就是一个发送触发源，PDU会依据传输模式决定是否可以立即发送。它不关心这次写入的值和上次是否相同，只要调用有效，就具备触发资格。
一个是“记下来再说”，一个是“写进去就走”。这个区别在调试里非常关键：如果一个信号被配成Pending，应用层怎么调用Com_SendSignal都不会推动PDU发送，必须在另一个Triggered信号或周期定时器到达时，数据才会被真正发出。
3.2 Triggered on Change：值变了才算数
Triggered On Change比Triggered多了一个前提条件：信号的新值和旧值比，必须发生了变化，才会触发PDU发送；如果应用层经常写同一个值，比如一直在写0x55，那么PDU不会因为这个信号发送。
这个“值变化判断”在很多工具里本质上是把写入值跟Shadow Buffer（影子缓冲区）里的值做比较。这一点特别容易被忽略，我见过不止一次有人把计数字段设成Triggered On Change，结果计数器每帧都在自增，每次都满足“变化”条件，导致PDU退化和Direct模式没什么两样。后面我会专门讲这个坑。
Triggered On Change With Repetition则是在值变化触发的第一帧之后，按配置好的重复次数和重复周期，再补发若干帧，用来增强可靠性。它和“PDU级重复发送”的区别在于，前者只针对某一类变化事件生效，后者是PDU在满足触发条件后都会执行的增强行为。实际项目里不必太纠结词面差异，配置工具里一般都能一眼看出来。
3.3 一个PDU里多个信号的触发合并逻辑
一个PDU里多个信号可以分别配不同的Transfer Property，COM会把这些信号的触发条件做一个“或”的逻辑合并。翻译成人话就是：任何一个具备触发能力的信号满足触发条件，PDU就有资格被发送。
但注意，这里的“有资格”不等于“立即发送”。最终要不要发，还取决于PDU的Transmission Mode：
- PDU是Mixed模式：触发信号一旦满足条件，在时间窗口内就会立即发送。
- PDU是Periodic模式：触发信号只是把发送需求“记下来”，真正的发送时刻仍由周期定时器决定。
- PDU是Direct模式：只要有触发信号满足条件，立即发送。
我画了一条不太严格但很好用的判断线：Transmission Mode决定“PDU在什么时候允许发出去”；Transfer Property决定“信号更新时能不能充当扳机”。扳机扣了，要看枪的保险（传输模式）是不是处于允许发射的状态。
这个逻辑理解了，再去看工具里的配置就不会被绕晕。下面进入实战组合部分。
4. 组合配置与实践案例分析
4.1 典型业务场景的配置组合速查
不同业务场景对通信的需求差异很大，直接沿用一套配置模板很容易翻车。这里给一个在实际项目中总结的配置速查表，可以作为方案评审时的检查清单：
| 场景 | PDU Transmission Mode | 信号 Transfer Property |
|---|---|---|
| 普通周期状态报文（转速、温度、电压） | Periodic | 全部 Pending，或主状态信号 Pending |
| 高实时事件报文（碰撞、急刹、故障状态） | Direct | 主事件信号 Triggered 或 Triggered On Change |
| 状态+事件混合报文（门锁、车窗、挡位） | Mixed | 状态量 Pending，状态切换信号 Triggered On Change |
| 带计数器或滚码的周期报文 | Periodic 或 Mixed | 计数器信号必须 Pending，避免变化触发 |
| 低功耗唤醒/休眠确认类报文 | Direct + 重复发送 | 事件信号 Triggered On Change With Repetition |
| 网关路由类报文 | None | 按路由需求决定，本地不做主动调度 |
这个表不是金科玉律，但它覆盖了绝大多数控制器通信场景。实际评审时，拿到一个PDU，第一件事就是判断它到底是“周期类”“事件类”还是“混合类”，再统一决定PDU和信号的配置方向。
4.2 完整案例：一个门锁状态报文的配置全过程
我之前参与过一个车身控制器项目，有个报文专门上报门锁状态，PDU叫DoorLock_Status，总线周期要求10ms，包含三个信号：
- DoorLockStatus：门锁实际状态，枚举值，状态切换时需要立即上报。
- DoorLockAlarmCount：门锁报警计数值，累计次数，随时更新但不要求立即发送。
- AliveCounter：滚动计数器，每帧加1，供接收端做报文活性监控。
最开始有个同事把三个信号全配成了Triggered On Change，PDU配成Mixed，然后拉到CANoe上一看，发送间隔忽快忽慢，快的时候几乎几毫秒一帧，慢的时候又接近10ms，总线负载也明显比设计值高。
问题出在AliveCounter。它每帧都自增，必然满足“变化”条件，于是每一次应用更新它，都会触发PDU立即发送，整个PDU实际上被拖成了Direct模式，Mixed的时间窗口完全失效。计数器字段的本质作用是填充和校验，它不该成为发送触发源。正确配置应该是：PDU配Mixed，DoorLockStatus配Triggered On Change，DoorLockAlarmCount和AliveCounter都配Pending。
这样改完之后总线的行为变得非常符合预期：正常情况下每10ms一帧，接收端活性监控正常；门锁真正发生状态切换的那一瞬间，PDU被立即唤醒发送，实时性也有保障。
时间轴可以这样理解：0ms时周期定时器开始计时；2ms时门锁状态从Locked变为Unlocked，Triggered On Change生效，PDU立刻发出；3ms时AlarmCount被更新，因为Pending，只写缓冲区不触发；10ms周期到期，再发一帧，携带的是最新状态；后续没有状态变化的话，就稳定按10ms节奏发下去。这套看起来简单的配置，恰恰是项目里最容易犯错的环节。
4.3 配置工具落地与代码生成后的核对
实际项目中，AUTOSAR配置大多在EB tresos或DaVinci Configurator里完成。在EB tresos里，进入COM模块的配置树，找到目标I-PDU，可以设置Transmission Mode相关的参数；展开每个Signal，可以设置Transfer Property。DaVinci的操作路径类似，都是图形化下拉框配置，本质没有差别。
配置完不要急着生成代码。你要再确认一遍Arxml导出结果，尤其是在多个工具链之间流转的场景，配置可能被覆盖回默认值。生成代码后，推荐去Com_Cfg.c或者Com_PBcfg.c里核对一下实际生成的配置数组。比如信号传输属性通常会在按信号索引排列的数组里体现，PDU的传输参数会体现在按PDU索引排列的结构体里。不同版本的工具生成的宏名有差异，但都具备可读性，花五分钟扫一眼，远比盲信工具可靠。
有一个小技巧：把PDU里的信号按“主触发信号”“辅助信号”“纯填充信号”三类分好，再对照生成的数组逐条检查，很容易发现漏配和错配。
5. 调试心得与高频问题排查实录
5.1 总线负载异常升高，先查“每帧都在变”的信号
现象是设计上明明每个周期都算好了负载，实车抓下来却发现某个节点过了唤醒瞬间之后，总线使用率迟迟降不下来。这时候先别怀疑总线配置，去查那个PDU里是不是有信号配置成了Triggered On Change，而且应用层每次都在更新它。前面说的AliveCounter就是这个典型。还有一种情况是应用代码在循环里频繁调用Com_SendSignal写入同一个值，如果配的是Triggered而不是Triggered On Change，即使值没变，也会触发发送。尤其当这个PDU还是Mixed模式时，总线会被这种无意义的触发占满。
排查手段很简单：用CANoe统计每帧报文的实际间隔，做间隔分布图。如果某个报文的间隔出现大量接近0的小间隔，并且集中在某段时间，先把该PDU的信号传输属性逐个改成Pending，再对比总线负载变化，基本一轮就能锁定元凶。
5.2 调用了Com_SendSignal，报文却始终不出去
这个问题的排查顺序我建议是：先看PDU模式，再看信号属性，再看返回值和函数调用是否正确。一个工程师在应用代码里调用了Com_SendSignal，返回值是E_OK，但总线上抓不到报文。查了半天，发现该PDU配的是Periodic模式，周期定时器虽然启动了，可PDU的“有效数据”一直没有被标记为Ready。因为该PDU里所有信号都是Pending，而Periodic模式在工具链里，如果配置了发送条件且条件一直不满足，是可能不发送的。
如果确认PDU模式没问题，再检查是不是误用了Com_UpdateShadowSignal。这个函数只更新影子值，不会触发发送判断。很多从其他通信协议栈转过来的工程师会顺手用它写信号，导致COM不自知。再有就是检查信号是否被人为置为Invalid，PDU在Invalid状态下通常不会进入发送队列。
5.3 接收端报超时，发送端却在老实发周期报文
事件型发送和周期监控天然存在冲突。接收端如果做了Timeout Monitoring，依赖的是“每隔一段时间必定有一帧”这个假设；而发送端一旦把某些信号改成Triggered On Change，在长时间没有状态变化的场景下，PDU可能很久都不发，接收端的超时监控就会误报。
我处理过一个真实案例：某控制器上报一个诊断类的状态值，平时几乎不变，改成事件触发后总线负载明显下降，但接收端频繁报“通信超时”。最后把接收端的超时阈值从100ms放宽到1s，同时保留发送端在进入故障模式时用重复发送机制补发几帧，问题才解决。
这里有个原则要记住：任何报文如果承担了活性监控或新鲜度监控的职责，就必须保证在监控周期内有至少一帧发出。要么维持Periodic模式，要么把ComTxModeTimePeriod设成小于接收端监控阈值。事件触发省流量，但代价是接收端不能用传统方式做超时监控。
5.4 初始化阶段首帧丢失的三种原因
上电后第一帧报文迟迟不来，也是高频问题。常见原因有三种：
一是初始化快照和首帧写入值相同，Triggered On Change认为“没变化”，不触发发送。解决办法是在初始化阶段把信号快照设成一个不可能出现在正常报文里的值，或者在初始化流程里手动调用Com_TriggerTransmission强制发一帧。
二是PDU的发送状态机在通信启动后还没有完成初始化，应用层写入过早，数据被丢弃。这种情况需要核对Com_Init以及通信模式切换的时序，确保应用在COM进入通信状态后再写信号。
三是重复发送次数配为0，事件信号首帧发出后接收端可能没准备好，尤其是总线网络管理还在建立期间，首帧丢失后没有补帧。对于唤醒场景，建议事件信号配置Triggered On Change With Repetition，多送几帧更稳妥。
5.5 信号组混用传输属性容易出“数据对不上”的问题
使用Com_SendSignalGroup批量更新信号时，如果组内信号属性混用，会出现一种很隐蔽的现象：信号组更新完成后，接收端解析到的数据是“新一半旧一半”。原因在于PDU发送请求发生在组内某个触发信号写入时，而另外几个Pending信号还没轮到写入，PDU就已经被发送出去了。
解决思路有两条：一是同一信号组内的信号，保持相同的传输属性，尽量让主触发信号放在组内最后写入；二是在设计阶段把信号组和PDU的映射关系梳理清楚，确认发送逻辑不会拆散一组原子信号。如果业务上确实无法避免，就要在代码里通过临时变量缓存，等一组信号全部准备完成后，再统一触发发送。
最后再分享一点个人体会
这两个参数，如果只看AUTOSAR规范文档，很容易当成死记硬背的配置项；一旦连着抓几轮总线波形，被负载和超时问题折磨过，才会真正理解它们配合出来的行为逻辑。我给新同事的建议一直是：拿到一个PDU，先判断它是周期类、事件类还是混合类，再决定Transmission Mode；然后把每个信号按实时性需求逐个确定Transfer Property。顺序一旦反过来，要么总线浪费严重，要么事件响应迟钝，后面会花成倍的时间在实车上返工。配置本身不复杂，难的是理解每个参数在总线上到底会引起什么反应。
