4、消息层协议（二）：RSM、RSI、MAP协议详解

好，咱们接着聊消息层协议。上一节我们把BSM和V2X的基础通信模型讲透了，这一节我重点说说路侧那三个核心消息——RSM、RSI和MAP。说实话，这三个协议在实际项目中踩坑最多，也最容易被忽视。

4.1 RSM：路侧安全消息

RSM的全称是Road Side Safety Message，路侧安全消息。说白了，就是路侧设备在替那些“看不见”的交通参与者发声。

RSM的核心作用是什么？

路侧感知设备（比如摄像头、毫米波雷达、激光雷达）检测到行人、非机动车、障碍物，但这些目标本身没有V2X通信能力。这时候RSU就得替它们发RSM，告诉周围的车辆：“嘿，注意！你左边3米有个骑自行车的人。”

RSM的消息结构

我直接给个典型的数据帧结构，你们感受一下：

// RSM 核心数据帧（简化版）
message RoadSideSafetyMessage {
  // 消息头
  int32 msgCnt;           // 消息计数器
  int32 id;               // 路侧设备ID
  
  // 参与者列表（核心）
  repeated Participant participants {
    int32 ptcType;        // 参与者类型：1-行人, 2-自行车, 3-摩托车...
    int32 ptcId;          // 参与者ID
    Position3D pos;       // 经纬度+高程
    int32 speed;          // 速度（0.02m/s为单位）
    int32 heading;        // 航向角（0.0125度为单位）
    int32 size;           // 目标尺寸
  }
  
  // 可选扩展
  optional int32 equipmentType;  // 路侧设备类型
}

嗯，这里要注意。ptcType这个字段，我见过不少项目把它搞混。行人、自行车、摩托车、动物……每个类型都有固定编号，千万别自己发明。我曾经在一个项目中看到有人把“电动滑板车”填成了“摩托车”，结果车辆预警逻辑全乱了。

4.2 RSI：路侧信息

RSI，Road Side Information。这个跟RSM不一样，RSI不是报目标，而是报“事件”和“状态”。

RSI的应用场景

• 前方施工预警
• 交通事故提醒
• 恶劣天气提示（团雾、结冰）
• 限速、车道关闭等交通管制信息
• 特殊车辆优先通行（比如救护车）

我个人习惯把RSI理解为“路侧的广播系统”。它不关心具体是谁在路上，它只关心路上发生了什么。

RSI的消息结构

// RSI 核心数据帧（简化版）
message RoadSideInformation {
  int32 msgCnt;
  int32 id;
  
  // 事件列表
  repeated Event events {
    int32 eventType;      // 事件类型：1-施工, 2-事故, 3-恶劣天气...
    Position3D pos;       // 事件位置
    int32 radius;         // 影响半径（米）
    int32 duration;       // 预计持续时间（秒）
    optional string description;  // 文字描述
  }
}

你想想看，如果RSI发出去的事件类型是“事故”，但实际只是施工，车辆可能会触发紧急制动。这多危险。

4.3 MAP：地图消息

MAP消息，全称Map Data。这个协议我得多说两句，因为它是V2X里最容易被低估的协议。

MAP消息到底在传什么？

MAP消息传的不是高精地图，而是“路口拓扑结构”。说白了，就是告诉车辆：这个路口有几个车道、车道之间怎么连接、红绿灯在哪个位置、停止线在哪里。

为什么需要MAP？

没有MAP，车辆只知道“我在路口”，但不知道“我在哪个车道”、“我能不能左转”。MAP就是给车辆提供“路口级”的语义理解能力。

MAP的核心要素

要素	说明	示例
节点（Node）	路口的中心点	经纬度坐标
车道（Lane）	每个车道的几何形状	车道宽度3.5m，长度50m
连接关系（ConnectsTo）	车道之间的转向关系	车道1可以左转到车道3
信号灯组（SignalGroup）	每个车道对应的红绿灯	车道1对应信号灯组A

MAP消息的典型结构

// MAP 核心数据帧（简化版）
message MapData {
  int32 msgCnt;
  int32 id;
  
  // 路口列表
  repeated Intersection intersections {
    int32 intersectionId;
    Position3D refPoint;      // 路口参考点
    
    // 车道列表
    repeated Lane lanes {
      int32 laneId;
      int32 laneWidth;        // 车道宽度（厘米）
      repeated Point nodeList; // 车道中心线节点
      
      // 连接关系
      repeated ConnectsTo connectsTo {
        int32 connectingLaneId;
        int32 signalGroupId;  // 关联的信号灯组
      }
    }
  }
}

4.4 三个协议的协同关系

RSM、RSI、MAP这三个协议，在实际系统中是协同工作的。我画个简单的逻辑关系：

• MAP 提供“静态”的路口拓扑
• RSM 提供“动态”的目标信息
• RSI 提供“事件”级别的路侧信息

举个例子你就明白了：

车辆收到MAP消息，知道前方路口有3条车道，自己当前在中间车道。接着收到RSM消息，发现右侧车道有一个行人正在横穿。再收到RSI消息，提示前方50米有施工。车辆综合这三个消息，做出决策：减速、向右变道、注意行人。

你看，少了任何一个协议，这个决策链就不完整。

4.5 实际项目中的常见问题

我总结几个我在项目中踩过的坑：

1. RSM的参与者ID冲突：多个RSU同时检测到同一个行人，各自分配了不同的ptcId，导致车辆收到重复目标。解决方案：引入全局ID分配机制。
2. RSI的事件过期问题：施工结束了，但RSI还在广播。我曾经见过一个项目，施工结束3小时后还在发预警。一定要加duration字段，并且RSU要定期清理过期事件。
3. MAP的车道编号不一致：不同路口的车道编号规则不统一，有的从右往左数，有的从左往右数。建议统一采用“从道路中心线向外侧递增”的规则。

好了，这一节的内容就到这儿。下一节我们讲SPAT和BSM的深度应用，特别是信号灯相位与车辆轨迹的匹配算法。那个更有意思。