T/CITSA 53-2025 智慧高速公路 跨运营主体的交通状态信息交互要求

本文档（T/CITSA 53-2025）由中国智能交通协会归口管理，由北京速通科技有限公司等单位起草，旨在规范智慧高速公路中不同运营主体之间的交通状态信息交互。标准适用于高速公路网互通路段的跨运营主体信息交互的设计、建设和管理，涉及交通状态数据的采集、传输、接口和安全要求。文档基于GB/T 1.1-2020等国家标准起草，可能涉及专利但发布机构不承担识别责任。

​1. 范围​

本文件规定了跨运营主体交通状态信息交互的基本框架，包括：

• 适用场景：高速公路网中互通的不同运营主体（如收费公司或路段管理单位）之间的信息交互。
• 核心内容：涵盖交互区域定义、交互内容分类（静态和动态信息）、传输协议、数据接口格式及信息安全措施。
• 目标用户：适用于设计、建设和管理的工程人员，强调互通路段的协同运营。

​2. 规范性引用文件​

文档引用了多个国家标准和行业规范，作为技术依据：

• ​关键引用​：包括GB/T 917（公路路线标识）、GB/T 29100（交通事件分类与编码）、GB/T 29744（道路编码规则）、JT/T 132（公路数据库编目）、JT/T 697.2（公路信息基础数据元）、YD/T 3709（车联网通信技术）和T/CITSA 37（智慧高速公路分级）。
• ​适用原则​：注日期的引用文件仅对应版本有效；不注日期的文件适用最新版（包括修改单）。

​3. 术语、定义和缩略语​

• ​运营主体（Operator）​​：负责特定路段收费、运营管理和养护的法人单位，职责包括公路运营、设施维护、交通信息采集与发布、安全保障等。
• ​跨运营主体（Cross Operators）​​：指有1条及以上互通公路的两个或多个不同运营主体。
• ​公路交汇点（Road junctions）​​：跨运营主体公路互通的位置，如收费站、互通立交桥或分界桩。

文档定义了常用缩略语，包括：

• ​CSV​：逗号分隔值（Comma-Separated Values）
• ​HTTP/HTTPS​：超文本传输协议/安全协议（Hyper Text Transport Protocol/Secure）
• ​JSON​：JavaScript对象简谱（JavaScript Object Notation）
• ​MQ/MQTT​：消息队列/消息队列遥测传输协议（Message Queue/Message Queuing Telemetry Transport）
• ​RSU​：路侧单元（Road Side Unit）
• ​XML​：可扩展标记语言（EXtensible Markup Language）

​4. 基本要求​

定义信息交互的地理范围，确保互通路段的数据共享：

• ​区域范围​：以公路交汇点为中心的可通达区域，推荐为交汇点起0-10公里内的高速公路（包括单向或双向通达）。例如，两个交汇点间距小于等于交互区域长度时，交互区域为两点间路段。
• ​特殊规则​：高速公路与非高速公路互通时，如无收费站隔离，非高速路段纳入交互区域；否则不纳入。各运营方可根据交通流量、事故风险等因素协商具体范围。
• ​可视化示例​：图1展示了跨运营主体公路互通模型，其中阴影区域代表交互区域（如运营主体2和3在交汇点C附近的路段）。
  

分为静态和动态信息，运营方可基于实际需求约定细节：

• ​静态信息​：公路基础数据，包括：
  • 设计参数：如桥梁、隧道、服务区、收费设施、情报板。
  • 设施设备状态：如监控、收费、通信、照明、供配电、隧道机电设施。
• ​动态信息​：实时交通状态数据，包括：
  • 交通参与者信息：车辆、行人、遗撒物等。
  • 交通事件信息：拥堵、事故、施工等。
  • 公路气象信息：风、雾、冻雨等。

定义信息传输架构和模式：

• ​信息交互架构​：采用中心端标准化接口（见图2），确保跨主体数据高效流转。

   

• ​交互模式​：
  • ​订阅​：接收方自动读取发送方的数据队列，适用于连续数据（如车辆位置信息），要求数据连续性、完整性和准确性。
  • ​查询​：接收方主动发起请求（如查询特定事件或位置），发送方实时响应。
  • ​推送​：发送方自动或人工发送数据（如恶劣气象或交通事件），无需接收方请求。

​5. 交互信息传输要求​

规范数据传输的介质、协议和频次：

• ​5.1 通信介质​：可选用光纤、4G/5G/6G或其组合，由交互双方约定。
• ​5.2 传输协议​：
  • 低频业务（如静态信息）宜用HTTP/HTTPS协议。
  • 高频业务（如车辆状态、事件发布）宜用MQ或MQTT协议。
  • 数据格式推荐JSON，可选XML或CSV。
• ​5.3 传输频次​：
  • ​静态信息​：周期性传输，频次宜每日1次。
  • ​动态信息​：频次要求严格（见表1）：
    

    序号	信息类型	信息内容	传输要求
    1	交通参与者信息	车辆、行人遗撒物等	周期性实时更新，最小周期≤5秒
    2	公路气象信息	风、团雾、冻雨等	无气象时周期30分钟；有气象时最小周期≤10秒
    3	交通事件信息	拥堵、事故、施工等	无事件时周期30分钟；有事件时最小周期≤10秒

​6. 交互信息数据接口要求​

规范数据结构和格式：

• ​6.1 一般格式​：
  • ​数据帧结构​（见表2）：由消息头（Head、Type、Length）和消息体（Data）组成，以CRC校验码结尾。消息头标识符为FFH，数据类型包括查询（0）、推送（1）、订阅（2）。
    

    序号	字节数	参数	说明
    1	2	Head	消息头标识，取值FFH
    2	1	Type	数据类型（0-查询,1-推送,2-订阅）
    3	4	Length	数据总长度（含头和体）
    4	N	Data	消息体内容
    5	2	CRC	异或校验码

  • ​时空基准​：坐标系推荐CGCS2000（可选GCJ-02），时间基准为北京时间（误差≤5毫秒）。
• ​6.2 静态信息​（消息体格式见表3）：
  • 必选字段：ID（0表示静态信息）、时间戳、行政区编码（adcode）、道路编号（roadId）、路段编号（roadSectionId）、车道数量（laneNumber）、车道方向（direction，1为桩号增加，2为减少）、起终点经纬度及桩号。
  • 示例字段：道路设计参数（如laneNumber）、设施状态（如Service维护状态）。
• ​6.3 动态信息​：
  • ​交通参与者信息​（见表4）：ID取值1，必选字段包括类型（0-机动车,1-非机动车等）、车辆类型（参考YD/T 3709）、车道号、位置（经纬度）、速度、车牌信息（如plateNo）、ETC状态。
  • ​交通事件信息​（见表5）：ID取值2，必选字段包括事件位置（经纬度、桩号）、事件类型（如JTSG表示交通事故）、事件等级（1-4级）、发生时间。事件类型编码遵循GB/T 29100。
  • ​公路气象信息​（见表6）：ID取值3，必选字段包括位置、路面温度、气温、能见度、湿度、风速风向、降水量及灾害指标（如Fog雾等级1-10）。

​7. 信息安全要求​

确保数据保密性和完整性：

• ​7.1 信息加密​：传输分为不加密和加密模式。加密时须使用校验或密码技术保证数据完整性。
• ​7.2 加密方式​：
  • ​HTTP协议加密​：采用token验证流程，包括分配客户端标识/密钥、申请token、校验后数据推送（携带token）。
  • ​MQ通信加密​：通过用户名、密码和SSL证书认证，分配数据读写权限。
• ​7.3 授权​：隐私信息（如交通参与者数据）需基于OAuth2.0框架授权，使用客户端标识和密钥获取accessToken。
• ​7.4 数据存储和销毁​：发送方不维持数据队列；接收方存储策略：
  • 静态信息：存储6个月（每日更新则顺延）。
  • 动态信息：存储3个月后销毁。

此总结覆盖文档全部核心内容，包括定义、要求、技术细节及安全措施。结构上分章节详述，并嵌入相关图片以还原文档上下文。如需特定部分深入解释，请随时提问！