CAN系列 --- (1) 一帧 CAN 报文在 ECU 中的完整生命周期
CAN系列 --- (2) CAN 接收中断是如何触发的？一帧一中断真的合理吗？
CAN系列 --- (3) Radar Object List 在 MCU 内部是如何被拼装、校验并最终被消费的？
CAN系列 --- (4) Radar Header 报文：为什么它是 MCU 感知周期的"锚点"
CAN系列 --- (5) COM / PduR / CanIf 的职责边界：为什么它们不能互相越界
CAN系列 --- (6) CAN FD 带宽、CPU、中断：工程上是如何一起算的？
CAN系列 --- (7) Alive、Counter、Timeout：CAN 报文里的功能安全不是"多几个字段"
CAN系列 --- (8) 为什么 Radar Object List 不适合"直接走 CAN 信号"
在很多 CAN 项目早期，尤其是功能刚起、团队还没被数据量打过脸的时候，常常会出现一种看起来非常"规范"的设计：
Radar Object List
→ 拆成 CAN Signals
→ 走 COM
→ 自动生成 RTE 接口
→ Application 直接用 signal
从 AUTOSAR 教科书角度看，这几乎是最"标准"的做法。
但奇怪的是------
很多感知项目做到中后期，都会把这条路推翻。
甚至你会看到架构决策里写着：
"Object List 不再通过 COM signal 解析，改为 Raw PDU 处理。"
这一篇，我们就来认真回答三个问题：
- Signal / PDU / Raw Frame 到底差在哪
- 为什么 Object List 会"天然排斥"Signal 语义
- CAN 在感知系统里的边界到底在哪里
1. Signal / PDU / Raw Frame：不是抽象层级，是"语义承载能力"
我们先不谈好坏，只谈它们各自"擅长表达什么"。
1.1 Signal：为"稳定、独立、可校验变量"而生
CAN Signal 非常适合：
- Wheel Speed
- Yaw Rate
- Gear Position
- Temperature
- Enable / Status Flag
它们有共同特点：
- 语义稳定
- 生命周期独立
- 单个信号即有工程意义
- 可被独立校验（range / timeout / alive）
👉 Signal 的世界里，"每一个量都值得被认真对待"。
1.2 PDU：为"结构化数据单元"服务
PDU 更像是：
- 一个逻辑数据块
- 内部字段彼此关联
- 生命周期一致
比如：
- Radar Header
- ECU Status
- Vehicle State Snapshot
PDU 的语义是：
"这是一组要一起理解的数据。"
1.3 Raw Frame：为"算法输出"和"协议自管理"留的后门
Raw Frame（或 Raw PDU Buffer）通常意味着：
- 不走 signal unpack
- 接收侧自行解析
- 应用代码直接感知字节布局
这在控制系统 里是异端，
但在感知系统里，却越来越常见。
原因就在 Radar Object List 本身。
2. Radar Object List：它"看起来像信号"，但本质不是
2.1 Object List 的真实属性
Radar Object List 具有几个非常"反 Signal"的特性：
- 对象数量是动态的
- 对象之间有强关联（同一感知周期）
- 单个 Object 脱离 List 没有完整语义
- 丢 1 帧 ≠ 功能失败
- 生命周期由 Header / Cycle 定义，而不是单信号
从语义上讲：
Object List 是一次算法"输出结果"，不是一组独立测量量。
2.2 Signal 化之后会发生什么？
假设你坚持：
- 每个 Object 的 x / y / v / r
- 都定义为 COM Signal
那么你立刻会遇到这些问题：
① 生命周期被撕裂
COM 看到的是：
- Signal A timeout
- Signal B 正常
- Signal C alive 跳变
但算法需要的是：
"这一帧 Object List 是否完整、可信、属于同一个周期"
👉 Signal 把"整体语义"拆碎了。
② 功能安全语义错位
你会开始纠结：
- Alive 放在哪个 signal？
- 每个 object 都要 counter 吗？
- 丢一个 object 是 fault 吗？
最后发现：
Signal 层的安全机制，无法正确映射 Object List 的安全语义。
③ 性能成本被放大
COM Signal 带来的不是"免费抽象"：
- unpack
- scaling
- endianness
- RTE copy
- per-signal callback
当 Object 数量上来时：
CPU 消耗是按"信号数"线性放大的。
而算法真正关心的是：
- 一整块 object buffer
3. 为什么很多项目后期会"推倒 COM 直解"
这是一个非常真实的工程演化路径。
3.1 初期：信号化 = 快速集成
在项目早期：
- 对象少
- 带宽低
- 验证场景简单
Signal 化带来的好处非常明显：
- 快速接入 RTE
- 工具链友好
- 调试方便
👉 这是合理的工程选择。
3.2 中期：复杂度开始反噬
当系统开始出现：
- 多雷达
- 更高 object density
- 更严格的 CPU / latency budget
你会发现：
- COM 配置爆炸
- Timeout / Alive 配不清
- 性能瓶颈难以定位
这时你会意识到：
问题不是"配置不够好"，而是抽象层选错了。
3.3 后期：回到"感知语义驱动"的设计
于是你会看到这些变化：
-
Header 仍然走 COM（周期锚点 + 功能心跳）
-
Object Data 走 Raw PDU
-
Application 自行管理：
- cycle
- completeness
- validity
- safety state
这不是"反 AUTOSAR"，
而是：
尊重数据本身的工程语义。
4. CAN 在感知系统里的边界在哪里？
这是这一篇真正想回答的问题。
4.1 CAN 擅长做什么？
CAN 非常擅长：
- 小而稳定的状态量
- 周期性心跳
- 功能状态同步
- 安全监控锚点
比如：
- Radar Header
- Sensor Status
- Mode / Health
4.2 CAN 不擅长什么？
CAN 不擅长：
- 承载"算法结果集合"
- 表达动态结构
- 承担感知内部数据模型
👉 CAN 是"接口边界"，不是"算法内部总线"。
5. 总结
Radar Object List 看起来像一组 CAN 信号,但它的工程语义更接近一次"算法输出快照"。 Signal 适合独立变量， PDU 适合结构化状态， 而感知结果集合，往往需要越过 Signal 抽象。
这不是对 CAN 的否定， 而是对 CAN 在感知系统中边界的尊重。