简介这份CSAE 53-2020《合作式智能运输系统 车用通信系统 应用层及应用数据交互标准第一阶段》PDF面向智能网联汽车、V2X车路协同、ITS应用开发与测试人员也适合相关专业师生查阅。它聚焦车用通信系统应用层规范与数据交互要求给出系统架构、术语缩略语、需求分析及基础应用定义可帮助读者统一对前向碰撞预警、交叉路口碰撞预警、左转辅助、盲区/变道预警、逆向超车预警、紧急制动预警等场景的理解。压缩包内共1个PDF文件大小15.57MB为标准全文便于检索目录、引用条款和对照研发。已有1274人学习说明其在车路协同与V2X工程实践中具有较高参考价值读者可从中获取应用层数据交互框架、场景基本要求与标准引用关系用于方案设计、测试用例梳理、项目合规对照及论文写作。1. 一句话说清这份标准一套让车与车“对得上话”的语法书两台车在路上交会前后不过两三秒。人靠眼神、喇叭和转向灯打招呼车靠什么靠一套双方都认得的说法我在哪、多快、朝哪走、踩没踩刹车。CSAE 53-2020《合作式智能运输系统 车用通信系统 应用层及应用数据交互标准第一阶段》管的正是这套说法——它不规定你用哪种无线技术把信号发出去只规定消息长什么样、字段怎么填、什么情况下该给驾驶员报警。搞懂它你就明白车与车对话的“语法书”是怎么一页页写出来的也才看得懂路上那些自称“能通信”的车到底在互相说些什么。2. 车里到底在传什么从“喇叭和转向灯”到一套消息集2.1 为什么车与车之间必须先有“共同语言”合作式智能运输系统这个词听着大拆开其实很朴素让车、路、人三方的信息互相流通——车知道前面路口现在是什么灯路知道哪台车快要刹不住人知道旁边那台车准备并线。标准给的定义是“通过人、车、路信息交互实现车辆和基础设施之间、车辆与车辆之间、车辆与人之间的智能协同与配合”。重音落在“协同”上它不是让某一台车自己变得更聪明而是让每台车提前知道别人打算干什么。要干这件事车上得有一套硬件。标准以车载单元OBU为例把一台车拆成四个子系统无线电通信子系统负责收发空中信号一台设备里可以装一个也可以装多个定位系统通常包含卫星导航接收器提供位置、方向、速度和时间还可以用车速信号、惯性测量单元、差分定位来做增强车载设备处理单元负责生成要发出去的信号、处理收到的信号天线完成射频信号的收发。这套东西通过接口连到应用电子控制单元再由人机交互界面用图像、声音、振动提醒驾驶员。有时候应用电子控制单元和车载设备处理单元干脆做在同一个物理盒子里。打个比方单车智能的摄像头和雷达像手电筒只能照见自己看得见的地方车用通信更像对讲机能让前车把“我这儿有个坑”直接喊给你听。手电筒照不到遮挡物后面对讲机可以。这一点在后面讲前向碰撞预警的第四个场景时会体现得非常清楚。2.2 应用层站在七层模型的哪一级参考国际上通信系统的七层参考模型车用通信系统通常被划成系统应用、应用层、传输层、网络层、数据链路层和物理层。这份文件把边界划得很干脆只管应用层以及应用层与上下相邻两层的两个接口。往上一层的接口是应用程序编程接口API往下一层的接口是服务提供者接口SPI。这个分工的意义在于解耦。向上的 API 让不同应用开发者可以各自开发应用不用操心底下用的是什么通信方式、什么通信设备向下的 SPI 让同一套应用层能对接不同通信方式的设备通信技术换代时上层不必推倒重来。通俗地说应用层规定的是“信封上该写哪些字、按什么格式写”至于这封信是骑自行车送还是开车送它一概不管。标准原文写得很直白本文件并不指定底层的通信技术可以用于各种不同的传输层、网络层、数据链路层和物理层。正因为砍掉了底层细节一份看起来只讲“数据长什么样”的文件才能真正跨厂商、跨设备地生效。你要做的车和你隔壁公司做的车不是同一个模组、不是同一个运营商网络但只要两边都按同一套消息格式说话语义就能对上。2.3 消息集的三层积木消息帧、数据帧、数据元素标准第 6 章是“应用层交互数据集”里面反复出现三个词消息帧、数据帧、数据元素。这三层是包含关系不是三个并列的东西。一个消息帧是路上真正发出去的那条“消息”里面装着若干数据帧数据帧再往下拆最小的格子叫数据元素。消息帧回答“这条消息是什么类型、是第几条”数据帧回答“这台车在哪儿、多快、朝哪”数据元素回答“纬度这个数字本身填多少”。用一段结构示意来感受层级关系字段名仅作示意真实定义以标准第 6 章的表格为准# 一条消息从外到内是信封 → 表格 → 格子三层 message_frame { msg_id: 0x02, # 消息帧层消息类型标识决定这是哪一类消息 msg_cnt: 128, # 消息帧层消息计数接收端据此判断有没有丢包 payload: { # 数据帧层一张表格把相关字段打包在一起 sender_id: …, # 发送方标识 position: { # 数据元素层最小的可填写的格子 lat: 0.0, # 纬度 lon: 0.0, # 经度 }, speed: 0.0, # 数据元素层速度 heading: 0.0, # 数据元素层航向角 }, }这段代码只看结构不要看数值msg_id决定接收端把这条消息交给哪个应用去处理msg_cnt是防丢包的序号payload里打包的是这台车的运动状态。真正写代码时这些字段都要按标准第 6.2 节的消息帧、数据帧、数据元素定义逐条对齐一个字段的类型、单位、取值范围错一位对面解出来就是另一台车的位置。编码方式也值得说一句。标准引用了抽象语法记法ASN.1系列规范和非对齐压缩编码规则UPER前者是描述数据结构的“语法”后者是把结构压成二进制比特的“打包机”。这样做的好处是省带宽、解析快代价是人类基本读不懂——一串十六进制扔在屏幕上没有规范文档对照就完全是黑匣子。这也解释了一个新手常见困惑为什么车联网调试常常要打印出“解码后”的结构体才看得懂直接抓包看到的全是天书。顺带说一个很容易被忽略的细节翻这份文件目录会发现第 6 章从第 43 页一路排到第 115 页其中“数据元素”一节独占第 76 到 115 页接近 40 页。也就是说整份标准里篇幅最大的部分不是场景描述而是把每一个字段的取值一格一格钉死。这恰恰是这类标准的价值所在讲道理的部分谁都能写难的是把“速度保留几位小数”这种细节统一到所有厂商都认。3. 为什么非要有一份标准三个绕不开的现实问题3.1 谁家的车都得对上话互联互通这道坎如果只有一家公司造会通信的车标准毫无必要——自家前后代产品对齐一下就行。现实是路上跑着几十个品牌的车路边立着不同厂商的路侧单元RSU。标准在系统介绍里把话说透了不同厂商车辆之间以及这些车辆与其所能到达区域内的道路基础设施之间必须实现互联互通。这句话翻译成工程语言就是只要互联不通装了设备也等于没装。这也解释了为什么这类标准不是闭门造车。它在规范性引用文件里同时挂了三类参照一类是国内的基础标准比如道路交通标志与标线、道路交通信号控制机的相关国标一类是 ASN.1 与编码规则的国标还有一类是国外的同类成果包括欧洲的基本应用集、北美的消息集字典和车载安全通信性能需求。更关键的一步是修订时把应用层交互数据集与国内车联网消息层技术要求对齐——上层的“说法”和下层的“消息层”必须咬合否则两边各说各话。打个比方这就像全国推广普通话不是否认方言的价值而是让一个南方人和一个北方人在火车站问路时不用比划。标准做的就是给“车语”定普通话而且明确说明自己只管“说什么”不管“用哪种嗓门说”。3.2 预警早了吓人、晚了没用性能指标为什么要写死安全类应用最难的从来不是“能不能算出来”而是“什么时候报”。报早了驾驶员被莫名其妙的警报吓一跳久而久之学会无视报晚了喊了也来不及踩。所以标准对每个应用都写了基本性能要求其中三个指标最关键定位精度、数据更新频率、系统延迟。系统延迟的定义值得逐字看从远车或路侧单元等设备发送通信数据后到主车接收该数据并通过网络层进行信息处理后传递给应用层的时间这份文件里特指应用层端到端的延迟。注意它没有把空口传输、编解码之外的环节都算进来——这是有意划出的责任边界谁的部分谁负责。2020 版相对 2017 版做了两处很能说明问题的调整。第一处是把交叉路口碰撞预警、左转辅助、异常车辆提醒、车辆失控预警、道路危险状况提示、限速预警、弱势交通参与者碰撞预警、绿波车速引导、车内标牌、紧急车辆提醒这十个应用的基本性能要求从“定位精度 ≤5 米”收紧到“≤1.5 米”。从工程角度看这个改动的用意不难猜城市路口两条车道并排横向间距也就三米出头五米的定位误差根本分不清你在本车道还是隔壁车道分不清车道“同车道前方有车”这个判断就成了玄学。第二处是把“数据更新频率 ≤”统一改成“数据更新频率典型值”。原来的写法很容易被读成一条硬性上限验收时变成扯皮点实验室偶尔跑到某个频率路上跑起来达不到算不算不合格改成典型值等于承认工程现实的波动把“必须达到某个数”换成“正常工作时大概是这个量级”。这种措辞上的微调背后往往是好几轮血泪经验的积累。3.3 应用开发者不该被通信技术绑死API 与 SPI 的分工第 7 章叫“应用层数据交互标准及接口规范”结构上分成三块应用层数据接口、API 接口先是一览表再是各接口的功能描述、SPI 接口同样是一览表加功能描述。这两个接口方向相反解决的问题也完全不同。接口方向谁在用解决什么问题API应用层向上对系统应用应用开发者不用关心底下用什么通信方式按统一接口取数据、发消息SPI应用层向下对通信设备设备与协议栈提供方换一种通信方式或通信设备时上层应用不用改表格里这两行看着平淡实际上是一套很聪明的分工。假设你是一家做前向碰撞预警算法的团队你最怕的是每换一个硬件供应商就要重写一遍取数逻辑。有了 SPI设备侧按统一接口把数据递上来有了 API你的算法按统一接口把预警递出去。通信技术从这一代换到下一代你的代码可能一行都不用动。反过来说如果你只盯着“某个模组怎么配置”而不看这两层接口那你的方案天然被绑死在一种通信方式上。这也是很多人读完标准后最常见的收获真正值钱的不是某个字段而是这套分层解耦的思路。4. 十七个一期应用怎么读安全、效率、信息服务三条线4.1 安全类应用从“前向碰撞预警”看一个应用是怎么被写清楚的一期应用一共 17 个安全类占了前 12 个前向碰撞预警、交叉路口碰撞预警、左转辅助、盲区预警/变道预警、逆向超车预警、紧急制动预警、异常车辆提醒、车辆失控预警、道路危险状况提示、限速预警、闯红灯预警、弱势交通参与者碰撞预警。剩下 4 个是效率类绿波车速引导、车内标牌、前方拥堵提醒、紧急车辆提醒1 个是信息服务类汽车近场支付。每个应用都按同样的六个方面描述应用定义和预期效果、主要场景、系统基本原理、通信方式、基本性能要求、数据交互需求。这个结构本身就是一种阅读方法——先看它想解决什么再看它在哪些场景下成立最后才看要传哪些字段。拿排第一的前向碰撞预警FCW当样本。定义很朴素主车HV在车道上行驶与正前方同一车道的远车RV存在追尾碰撞危险时对驾驶员预警。适用于普通道路或高速公路的追尾危险。它给了四个主要场景每一个都在回答“什么情况该报、什么情况不该报”第一个场景RV 在 HV 同一车道正前方停止HV 正常行驶过来即将碰撞时预警且预警时机要保证驾驶员收到后有时间采取措施。第二个场景最有意思RV 停在 HV 相邻车道的前方。标准明确写——HV 行驶过程中不会与 RV 发生碰撞驾驶员不会收到预警信息。也就是说这份文件不只规定“什么时候响”还规定“什么时候必须闭嘴”。误报和漏报同样是缺陷这一条是很多自己做 Demo 的人容易忽略的。第三个场景RV 在同一车道前方慢速或减速行驶同样要在即将碰撞时预警。第四个场景是这套技术真正的用武之地HV 跟着 RV-2 正常行驶RV-1 停在同车道更前面HV 的视线被 RV-2 完全遮挡RV-2 为了避开 RV-1 变道走了HV 面前突然出现一台静止车辆。此时 HV 和 RV-1 需要具备短程无线通信能力而中间的 RV-2 有没有通信能力都不影响场景成立。摄像头看不见被挡住的车通信可以。这就是“对讲机比手电筒强”的具体落点。判断危险用的是什么尺子标准里出现的是碰撞预计时间TTC和防撞距离CAV这类量。通俗地说就是拿两车的相对速度和距离算“还有几秒撞上”再拿这个秒数去比一个阈值。附录 C 是规范性附录专门给 FCW 的基本性能指标提供依据——注意“规范性”三个字它跟“资料性”附录的分量完全不同。4.2 效率类和信息服务类绿灯、标牌和一笔停车费效率类的四个应用共同点是都在跟路侧打交道。绿波车速引导GLOSA最典型路口信号机的相位和配时通过路侧单元广播出来车结合自己的位置和到路口的距离算出一个建议车速告诉你按这个速度走能连着过绿灯不用一脚油门一脚刹车。它省的不是某一台车的时间是一整条路口的通行波动。车内标牌IVS是把路侧的标志“投”进车里——实体的限速牌、警示牌信息通过通信送达在仪表或中控上呈现。前方拥堵提醒TJW是让路侧把前方的拥堵状况提前告诉你让你有机会换路。紧急车辆提醒EVW在标准的分类里归到了效率类通信方式是车与车逻辑是让执行任务的特种车辆把身份和位置广播出去让周围车辆提前让行。信息服务类只有一个汽车近场支付VNFP通信方式是车与路侧。把车当成一个支付终端在停车场、加油站这类近场场景完成扣费。它被单独列成一类说明这份文件对“安全、效率、信息服务”三分法的态度是务实的——不是按技术难度分而是按它给用户带来什么价值分。值得一提的是通信方式的标注方式。表里除了 V2V、V2I、V2P、V2V/V2I 这种组合还出现了 V2V-Event标在紧急制动预警、异常车辆提醒、车辆失控预警这三个应用上。带 Event 后缀意思是这类消息不必按固定节奏高频广播而是在事件发生时触发。紧急制动是瞬时的车辆失控是突发的异常车辆比如抛锚、货物散落也是偶发的按事件发既省带宽又更及时。理解这个后缀比记住三个缩略语有用得多。4.3 读性能要求时该盯哪三个数字定位精度、更新频率、时延翻任何一个应用的第“五”小节基本性能要求里反复出现的就是这三样。定位精度决定“你在哪条车道”这个判断能不能成立数据更新频率决定“你现在多快”这个信息有多新鲜系统延迟决定“你还有几秒撞上”这个结论是不是还成立。三者之间还有耦合。更新频率再高定位误差五米分不清车道前车判断就会错定位再准消息两秒才来一次算出来的 TTC 已经过期。所以标准在修订时是成组调整的——收紧定位精度、明确更新频率是典型值还要求数据集与下层消息层技术要求保持一致道理就在这里链条上任何一环松了整套预警的可用性就打折。读的时候还有一个实用技巧先看附录 B。它是资料性附录把一期应用按通信需求分了类。也就是说不用一个应用一个应用地啃先按“高频低时延”“低频可容忍”分组你就知道哪些应用对通信最挑剔哪些应用凑合一下也能跑。做方案时先攻哪一类一目了然。5. 五组最容易读歪的概念误区与区别5.1 误区一把 V2X 当成某一种具体的通信技术易混点很多人一看到 V2X脑子里立刻对应到某个具体的无线制式甚至以为这份标准就是那个技术的规范。为什么混缩写看起来很像技术名而且市面上讨论时经常把两者混着说。怎么区分标准对 V2X 的定义是“车载单元与其他设备通信包括但不限于车载单元之间通信V2V、车载单元与路侧单元通信V2I、车载单元与行人设备通信V2P、车载单元与网络之间通信V2N”。它描述的是一组“跟谁通信”的对象关系不是“用什么手段通信”。标准还专门声明不指定底层通信技术。所以正确的读法是V2X 是场景集合的名字具体用什么技术实现是另一层文件的事。5.2 误区二把应用层标准当成通信协议标准易混点以为照着这份文件就能把两台设备连起来通上。为什么混文件里确实有大量数据格式、编码规则、接口定义看起来非常“协议”。怎么区分看它的边界声明就知道——只管应用层及与上下相邻两层的接口传输层往下统统不管。它规定的是“说哪些话、话怎么组织”不规定“声音怎么传过去”。真正要打通链路还需要下层消息层技术要求、网络层与接入层的规范配合。这份文件里那些 ASN.1 和 UPER 的内容解决的是“同一句话怎么压缩成比特”不是“比特怎么发出去”。5.3 误区三把“定位精度 ≤1.5 米”读成“必须精确到 1.5 米”易混点拿到这条要求就去找能给出 1.5 米精度的定位模块找不到就认为方案不可行。为什么混不等号容易被略读成等号而且这个数字看起来很“绝对”。怎么区分≤是上限说的是误差不能超过这个量级不是要求每次都恰好 1.5 米。而且这条要求只落在修订时点名的那十个应用上并不是所有 17 个应用一刀切。更重要的是它是“基本性能要求”属于应用能正常工作的前提条件不是对单台设备出厂指标的承诺。工程上真正要问的是在我这个场景里定位误差超过多少判断就开始出错。5.4 误区四把“数据更新频率典型值”当成硬性上限易混点验收时拿一个实测频率去比对低了就判不合格高了又怕越界。为什么混2017 版原文用的是“≤”修订后改成“典型值”很多二手资料还在传旧说法。怎么区分典型值描述的是正常工作状态下的量级不是及格线也不是天花板。真正决定应用能不能用的是“消息够不够新”和“端到端延迟够不够小”这两件事的组合效果。如果你的方案在某段时间频率掉下去了但延迟仍在可接受范围未必就是致命问题反过来频率漂亮但延迟抖动大体验一样糟糕。5.5 误区五把团体标准当成强制性国家标准易混点看到封面上的标准编号和“实施”字样就以为是全国强制执行的国标。为什么混格式长得很像都有发布日期、实施日期、规范性引用文件、前言。怎么区分看编号前缀和发布主体性质。这类文件是行业团体组织发布的团体标准由行业自己定、自己用作用是给产业链一个共同的技术参照让不同厂商的设备能互通。它引用的 GB 开头文件是国家标准YD/T 开头是通信行业标准还有几份是国外行业组织的东西这几层关系别搅在一起。做合规判断时先弄清哪一份是“必须遵守”哪一份是“大家一起遵守比较好办事”。6. 什么时候该翻这份标准什么时候别浪费时间去翻判断标准很实际你手上的问题是“语义对齐”还是“物理实现”。如果是前者这份文件几乎绕不过去如果是后者它帮不上忙。该翻的几种情况。要开发车路协同应用尤其涉及安全类预警第 5 章每个应用的六个方面就是现成的需求清单场景描述可以直接拿去写测试用例——特别是那些“不该报警”的场景用来做负样本再合适不过。要和供应商或合作方对齐接口第 6 章的消息帧、数据帧、数据元素定义是共同语言比口头描述“大概发个位置速度”靠谱得多。要做验收或性能评估基本性能要求那一小节加附录 C是判断“这套东西到底行不行”的依据。要理解自家车为什么在某些情况下不报警或误报先看对应应用的主要场景往往能定位到是场景不成立还是判断阈值不合适。不必翻的几种情况。想学无线通信原理这份文件明确不管底层去读传输和接入层的材料更直接。想选型芯片、模组、天线这里没有器件参数只有数据格式。想解决单车感知问题摄像头和雷达的算法优化跟它无关它做的是“感知之外的信息补齐”。想看更高阶的协同驾驶或编队行驶注意副标题写着“第一阶段”17 个应用就是它的全部范围别指望在里面找到后面的东西。你手上的问题该去哪一部分这个应用在什么情况下该报警第 5 章对应应用的主要场景两个厂商的设备为什么对不上第 6 章数据集定义逐个字段核对我的应用要接不同厂商的硬件第 7 章 SPI 接口一览表验收时性能怎么算达标基本性能要求小节加规范性附录一期为什么选这 17 个应用资料性附录里的评选方法与需求分类底层用什么通信技术不在这里看下层规范有个习惯我用了很多年拿到任何一份这类文件先只读三处——范围、规范性引用文件、附录标注是“规范性”还是“资料性”。范围告诉你它管到哪儿为止引用文件告诉你它站在谁的肩膀上附录的标注告诉你哪些是真要求、哪些只是参考资料。这三页读完再决定要不要往下啃能省掉大把时间。早些年我反着来一头扎进数据集表格里逐行对照两天过去还没搞清这份文件到底管不管底层白折腾一场。从那以后每次都是先看这三页再决定翻不翻后面的几百页。需要对照原文细节的话完整的那份 PDF 就在资料里按上面这个顺序翻会比从头读到尾快得多。希望帮到你。本文还有配套的精品资源点击获取
简介这份CSAE 53-2020《合作式智能运输系统 车用通信系统 应用层及应用数据交互标准第一阶段》PDF面向智能网联汽车、V2X车路协同、ITS应用开发与测试人员也适合相关专业师生查阅。它聚焦车用通信系统应用层规范与数据交互要求给出系统架构、术语缩略语、需求分析及基础应用定义可帮助读者统一对前向碰撞预警、交叉路口碰撞预警、左转辅助、盲区/变道预警、逆向超车预警、紧急制动预警等场景的理解。压缩包内共1个PDF文件大小15.57MB为标准全文便于检索目录、引用条款和对照研发。已有1274人学习说明其在车路协同与V2X工程实践中具有较高参考价值读者可从中获取应用层数据交互框架、场景基本要求与标准引用关系用于方案设计、测试用例梳理、项目合规对照及论文写作。1. 一句话说清这份标准一套让车与车“对得上话”的语法书两台车在路上交会前后不过两三秒。人靠眼神、喇叭和转向灯打招呼车靠什么靠一套双方都认得的说法我在哪、多快、朝哪走、踩没踩刹车。CSAE 53-2020《合作式智能运输系统 车用通信系统 应用层及应用数据交互标准第一阶段》管的正是这套说法——它不规定你用哪种无线技术把信号发出去只规定消息长什么样、字段怎么填、什么情况下该给驾驶员报警。搞懂它你就明白车与车对话的“语法书”是怎么一页页写出来的也才看得懂路上那些自称“能通信”的车到底在互相说些什么。2. 车里到底在传什么从“喇叭和转向灯”到一套消息集2.1 为什么车与车之间必须先有“共同语言”合作式智能运输系统这个词听着大拆开其实很朴素让车、路、人三方的信息互相流通——车知道前面路口现在是什么灯路知道哪台车快要刹不住人知道旁边那台车准备并线。标准给的定义是“通过人、车、路信息交互实现车辆和基础设施之间、车辆与车辆之间、车辆与人之间的智能协同与配合”。重音落在“协同”上它不是让某一台车自己变得更聪明而是让每台车提前知道别人打算干什么。要干这件事车上得有一套硬件。标准以车载单元OBU为例把一台车拆成四个子系统无线电通信子系统负责收发空中信号一台设备里可以装一个也可以装多个定位系统通常包含卫星导航接收器提供位置、方向、速度和时间还可以用车速信号、惯性测量单元、差分定位来做增强车载设备处理单元负责生成要发出去的信号、处理收到的信号天线完成射频信号的收发。这套东西通过接口连到应用电子控制单元再由人机交互界面用图像、声音、振动提醒驾驶员。有时候应用电子控制单元和车载设备处理单元干脆做在同一个物理盒子里。打个比方单车智能的摄像头和雷达像手电筒只能照见自己看得见的地方车用通信更像对讲机能让前车把“我这儿有个坑”直接喊给你听。手电筒照不到遮挡物后面对讲机可以。这一点在后面讲前向碰撞预警的第四个场景时会体现得非常清楚。2.2 应用层站在七层模型的哪一级参考国际上通信系统的七层参考模型车用通信系统通常被划成系统应用、应用层、传输层、网络层、数据链路层和物理层。这份文件把边界划得很干脆只管应用层以及应用层与上下相邻两层的两个接口。往上一层的接口是应用程序编程接口API往下一层的接口是服务提供者接口SPI。这个分工的意义在于解耦。向上的 API 让不同应用开发者可以各自开发应用不用操心底下用的是什么通信方式、什么通信设备向下的 SPI 让同一套应用层能对接不同通信方式的设备通信技术换代时上层不必推倒重来。通俗地说应用层规定的是“信封上该写哪些字、按什么格式写”至于这封信是骑自行车送还是开车送它一概不管。标准原文写得很直白本文件并不指定底层的通信技术可以用于各种不同的传输层、网络层、数据链路层和物理层。正因为砍掉了底层细节一份看起来只讲“数据长什么样”的文件才能真正跨厂商、跨设备地生效。你要做的车和你隔壁公司做的车不是同一个模组、不是同一个运营商网络但只要两边都按同一套消息格式说话语义就能对上。2.3 消息集的三层积木消息帧、数据帧、数据元素标准第 6 章是“应用层交互数据集”里面反复出现三个词消息帧、数据帧、数据元素。这三层是包含关系不是三个并列的东西。一个消息帧是路上真正发出去的那条“消息”里面装着若干数据帧数据帧再往下拆最小的格子叫数据元素。消息帧回答“这条消息是什么类型、是第几条”数据帧回答“这台车在哪儿、多快、朝哪”数据元素回答“纬度这个数字本身填多少”。用一段结构示意来感受层级关系字段名仅作示意真实定义以标准第 6 章的表格为准# 一条消息从外到内是信封 → 表格 → 格子三层 message_frame { msg_id: 0x02, # 消息帧层消息类型标识决定这是哪一类消息 msg_cnt: 128, # 消息帧层消息计数接收端据此判断有没有丢包 payload: { # 数据帧层一张表格把相关字段打包在一起 sender_id: …, # 发送方标识 position: { # 数据元素层最小的可填写的格子 lat: 0.0, # 纬度 lon: 0.0, # 经度 }, speed: 0.0, # 数据元素层速度 heading: 0.0, # 数据元素层航向角 }, }这段代码只看结构不要看数值msg_id决定接收端把这条消息交给哪个应用去处理msg_cnt是防丢包的序号payload里打包的是这台车的运动状态。真正写代码时这些字段都要按标准第 6.2 节的消息帧、数据帧、数据元素定义逐条对齐一个字段的类型、单位、取值范围错一位对面解出来就是另一台车的位置。编码方式也值得说一句。标准引用了抽象语法记法ASN.1系列规范和非对齐压缩编码规则UPER前者是描述数据结构的“语法”后者是把结构压成二进制比特的“打包机”。这样做的好处是省带宽、解析快代价是人类基本读不懂——一串十六进制扔在屏幕上没有规范文档对照就完全是黑匣子。这也解释了一个新手常见困惑为什么车联网调试常常要打印出“解码后”的结构体才看得懂直接抓包看到的全是天书。顺带说一个很容易被忽略的细节翻这份文件目录会发现第 6 章从第 43 页一路排到第 115 页其中“数据元素”一节独占第 76 到 115 页接近 40 页。也就是说整份标准里篇幅最大的部分不是场景描述而是把每一个字段的取值一格一格钉死。这恰恰是这类标准的价值所在讲道理的部分谁都能写难的是把“速度保留几位小数”这种细节统一到所有厂商都认。3. 为什么非要有一份标准三个绕不开的现实问题3.1 谁家的车都得对上话互联互通这道坎如果只有一家公司造会通信的车标准毫无必要——自家前后代产品对齐一下就行。现实是路上跑着几十个品牌的车路边立着不同厂商的路侧单元RSU。标准在系统介绍里把话说透了不同厂商车辆之间以及这些车辆与其所能到达区域内的道路基础设施之间必须实现互联互通。这句话翻译成工程语言就是只要互联不通装了设备也等于没装。这也解释了为什么这类标准不是闭门造车。它在规范性引用文件里同时挂了三类参照一类是国内的基础标准比如道路交通标志与标线、道路交通信号控制机的相关国标一类是 ASN.1 与编码规则的国标还有一类是国外的同类成果包括欧洲的基本应用集、北美的消息集字典和车载安全通信性能需求。更关键的一步是修订时把应用层交互数据集与国内车联网消息层技术要求对齐——上层的“说法”和下层的“消息层”必须咬合否则两边各说各话。打个比方这就像全国推广普通话不是否认方言的价值而是让一个南方人和一个北方人在火车站问路时不用比划。标准做的就是给“车语”定普通话而且明确说明自己只管“说什么”不管“用哪种嗓门说”。3.2 预警早了吓人、晚了没用性能指标为什么要写死安全类应用最难的从来不是“能不能算出来”而是“什么时候报”。报早了驾驶员被莫名其妙的警报吓一跳久而久之学会无视报晚了喊了也来不及踩。所以标准对每个应用都写了基本性能要求其中三个指标最关键定位精度、数据更新频率、系统延迟。系统延迟的定义值得逐字看从远车或路侧单元等设备发送通信数据后到主车接收该数据并通过网络层进行信息处理后传递给应用层的时间这份文件里特指应用层端到端的延迟。注意它没有把空口传输、编解码之外的环节都算进来——这是有意划出的责任边界谁的部分谁负责。2020 版相对 2017 版做了两处很能说明问题的调整。第一处是把交叉路口碰撞预警、左转辅助、异常车辆提醒、车辆失控预警、道路危险状况提示、限速预警、弱势交通参与者碰撞预警、绿波车速引导、车内标牌、紧急车辆提醒这十个应用的基本性能要求从“定位精度 ≤5 米”收紧到“≤1.5 米”。从工程角度看这个改动的用意不难猜城市路口两条车道并排横向间距也就三米出头五米的定位误差根本分不清你在本车道还是隔壁车道分不清车道“同车道前方有车”这个判断就成了玄学。第二处是把“数据更新频率 ≤”统一改成“数据更新频率典型值”。原来的写法很容易被读成一条硬性上限验收时变成扯皮点实验室偶尔跑到某个频率路上跑起来达不到算不算不合格改成典型值等于承认工程现实的波动把“必须达到某个数”换成“正常工作时大概是这个量级”。这种措辞上的微调背后往往是好几轮血泪经验的积累。3.3 应用开发者不该被通信技术绑死API 与 SPI 的分工第 7 章叫“应用层数据交互标准及接口规范”结构上分成三块应用层数据接口、API 接口先是一览表再是各接口的功能描述、SPI 接口同样是一览表加功能描述。这两个接口方向相反解决的问题也完全不同。接口方向谁在用解决什么问题API应用层向上对系统应用应用开发者不用关心底下用什么通信方式按统一接口取数据、发消息SPI应用层向下对通信设备设备与协议栈提供方换一种通信方式或通信设备时上层应用不用改表格里这两行看着平淡实际上是一套很聪明的分工。假设你是一家做前向碰撞预警算法的团队你最怕的是每换一个硬件供应商就要重写一遍取数逻辑。有了 SPI设备侧按统一接口把数据递上来有了 API你的算法按统一接口把预警递出去。通信技术从这一代换到下一代你的代码可能一行都不用动。反过来说如果你只盯着“某个模组怎么配置”而不看这两层接口那你的方案天然被绑死在一种通信方式上。这也是很多人读完标准后最常见的收获真正值钱的不是某个字段而是这套分层解耦的思路。4. 十七个一期应用怎么读安全、效率、信息服务三条线4.1 安全类应用从“前向碰撞预警”看一个应用是怎么被写清楚的一期应用一共 17 个安全类占了前 12 个前向碰撞预警、交叉路口碰撞预警、左转辅助、盲区预警/变道预警、逆向超车预警、紧急制动预警、异常车辆提醒、车辆失控预警、道路危险状况提示、限速预警、闯红灯预警、弱势交通参与者碰撞预警。剩下 4 个是效率类绿波车速引导、车内标牌、前方拥堵提醒、紧急车辆提醒1 个是信息服务类汽车近场支付。每个应用都按同样的六个方面描述应用定义和预期效果、主要场景、系统基本原理、通信方式、基本性能要求、数据交互需求。这个结构本身就是一种阅读方法——先看它想解决什么再看它在哪些场景下成立最后才看要传哪些字段。拿排第一的前向碰撞预警FCW当样本。定义很朴素主车HV在车道上行驶与正前方同一车道的远车RV存在追尾碰撞危险时对驾驶员预警。适用于普通道路或高速公路的追尾危险。它给了四个主要场景每一个都在回答“什么情况该报、什么情况不该报”第一个场景RV 在 HV 同一车道正前方停止HV 正常行驶过来即将碰撞时预警且预警时机要保证驾驶员收到后有时间采取措施。第二个场景最有意思RV 停在 HV 相邻车道的前方。标准明确写——HV 行驶过程中不会与 RV 发生碰撞驾驶员不会收到预警信息。也就是说这份文件不只规定“什么时候响”还规定“什么时候必须闭嘴”。误报和漏报同样是缺陷这一条是很多自己做 Demo 的人容易忽略的。第三个场景RV 在同一车道前方慢速或减速行驶同样要在即将碰撞时预警。第四个场景是这套技术真正的用武之地HV 跟着 RV-2 正常行驶RV-1 停在同车道更前面HV 的视线被 RV-2 完全遮挡RV-2 为了避开 RV-1 变道走了HV 面前突然出现一台静止车辆。此时 HV 和 RV-1 需要具备短程无线通信能力而中间的 RV-2 有没有通信能力都不影响场景成立。摄像头看不见被挡住的车通信可以。这就是“对讲机比手电筒强”的具体落点。判断危险用的是什么尺子标准里出现的是碰撞预计时间TTC和防撞距离CAV这类量。通俗地说就是拿两车的相对速度和距离算“还有几秒撞上”再拿这个秒数去比一个阈值。附录 C 是规范性附录专门给 FCW 的基本性能指标提供依据——注意“规范性”三个字它跟“资料性”附录的分量完全不同。4.2 效率类和信息服务类绿灯、标牌和一笔停车费效率类的四个应用共同点是都在跟路侧打交道。绿波车速引导GLOSA最典型路口信号机的相位和配时通过路侧单元广播出来车结合自己的位置和到路口的距离算出一个建议车速告诉你按这个速度走能连着过绿灯不用一脚油门一脚刹车。它省的不是某一台车的时间是一整条路口的通行波动。车内标牌IVS是把路侧的标志“投”进车里——实体的限速牌、警示牌信息通过通信送达在仪表或中控上呈现。前方拥堵提醒TJW是让路侧把前方的拥堵状况提前告诉你让你有机会换路。紧急车辆提醒EVW在标准的分类里归到了效率类通信方式是车与车逻辑是让执行任务的特种车辆把身份和位置广播出去让周围车辆提前让行。信息服务类只有一个汽车近场支付VNFP通信方式是车与路侧。把车当成一个支付终端在停车场、加油站这类近场场景完成扣费。它被单独列成一类说明这份文件对“安全、效率、信息服务”三分法的态度是务实的——不是按技术难度分而是按它给用户带来什么价值分。值得一提的是通信方式的标注方式。表里除了 V2V、V2I、V2P、V2V/V2I 这种组合还出现了 V2V-Event标在紧急制动预警、异常车辆提醒、车辆失控预警这三个应用上。带 Event 后缀意思是这类消息不必按固定节奏高频广播而是在事件发生时触发。紧急制动是瞬时的车辆失控是突发的异常车辆比如抛锚、货物散落也是偶发的按事件发既省带宽又更及时。理解这个后缀比记住三个缩略语有用得多。4.3 读性能要求时该盯哪三个数字定位精度、更新频率、时延翻任何一个应用的第“五”小节基本性能要求里反复出现的就是这三样。定位精度决定“你在哪条车道”这个判断能不能成立数据更新频率决定“你现在多快”这个信息有多新鲜系统延迟决定“你还有几秒撞上”这个结论是不是还成立。三者之间还有耦合。更新频率再高定位误差五米分不清车道前车判断就会错定位再准消息两秒才来一次算出来的 TTC 已经过期。所以标准在修订时是成组调整的——收紧定位精度、明确更新频率是典型值还要求数据集与下层消息层技术要求保持一致道理就在这里链条上任何一环松了整套预警的可用性就打折。读的时候还有一个实用技巧先看附录 B。它是资料性附录把一期应用按通信需求分了类。也就是说不用一个应用一个应用地啃先按“高频低时延”“低频可容忍”分组你就知道哪些应用对通信最挑剔哪些应用凑合一下也能跑。做方案时先攻哪一类一目了然。5. 五组最容易读歪的概念误区与区别5.1 误区一把 V2X 当成某一种具体的通信技术易混点很多人一看到 V2X脑子里立刻对应到某个具体的无线制式甚至以为这份标准就是那个技术的规范。为什么混缩写看起来很像技术名而且市面上讨论时经常把两者混着说。怎么区分标准对 V2X 的定义是“车载单元与其他设备通信包括但不限于车载单元之间通信V2V、车载单元与路侧单元通信V2I、车载单元与行人设备通信V2P、车载单元与网络之间通信V2N”。它描述的是一组“跟谁通信”的对象关系不是“用什么手段通信”。标准还专门声明不指定底层通信技术。所以正确的读法是V2X 是场景集合的名字具体用什么技术实现是另一层文件的事。5.2 误区二把应用层标准当成通信协议标准易混点以为照着这份文件就能把两台设备连起来通上。为什么混文件里确实有大量数据格式、编码规则、接口定义看起来非常“协议”。怎么区分看它的边界声明就知道——只管应用层及与上下相邻两层的接口传输层往下统统不管。它规定的是“说哪些话、话怎么组织”不规定“声音怎么传过去”。真正要打通链路还需要下层消息层技术要求、网络层与接入层的规范配合。这份文件里那些 ASN.1 和 UPER 的内容解决的是“同一句话怎么压缩成比特”不是“比特怎么发出去”。5.3 误区三把“定位精度 ≤1.5 米”读成“必须精确到 1.5 米”易混点拿到这条要求就去找能给出 1.5 米精度的定位模块找不到就认为方案不可行。为什么混不等号容易被略读成等号而且这个数字看起来很“绝对”。怎么区分≤是上限说的是误差不能超过这个量级不是要求每次都恰好 1.5 米。而且这条要求只落在修订时点名的那十个应用上并不是所有 17 个应用一刀切。更重要的是它是“基本性能要求”属于应用能正常工作的前提条件不是对单台设备出厂指标的承诺。工程上真正要问的是在我这个场景里定位误差超过多少判断就开始出错。5.4 误区四把“数据更新频率典型值”当成硬性上限易混点验收时拿一个实测频率去比对低了就判不合格高了又怕越界。为什么混2017 版原文用的是“≤”修订后改成“典型值”很多二手资料还在传旧说法。怎么区分典型值描述的是正常工作状态下的量级不是及格线也不是天花板。真正决定应用能不能用的是“消息够不够新”和“端到端延迟够不够小”这两件事的组合效果。如果你的方案在某段时间频率掉下去了但延迟仍在可接受范围未必就是致命问题反过来频率漂亮但延迟抖动大体验一样糟糕。5.5 误区五把团体标准当成强制性国家标准易混点看到封面上的标准编号和“实施”字样就以为是全国强制执行的国标。为什么混格式长得很像都有发布日期、实施日期、规范性引用文件、前言。怎么区分看编号前缀和发布主体性质。这类文件是行业团体组织发布的团体标准由行业自己定、自己用作用是给产业链一个共同的技术参照让不同厂商的设备能互通。它引用的 GB 开头文件是国家标准YD/T 开头是通信行业标准还有几份是国外行业组织的东西这几层关系别搅在一起。做合规判断时先弄清哪一份是“必须遵守”哪一份是“大家一起遵守比较好办事”。6. 什么时候该翻这份标准什么时候别浪费时间去翻判断标准很实际你手上的问题是“语义对齐”还是“物理实现”。如果是前者这份文件几乎绕不过去如果是后者它帮不上忙。该翻的几种情况。要开发车路协同应用尤其涉及安全类预警第 5 章每个应用的六个方面就是现成的需求清单场景描述可以直接拿去写测试用例——特别是那些“不该报警”的场景用来做负样本再合适不过。要和供应商或合作方对齐接口第 6 章的消息帧、数据帧、数据元素定义是共同语言比口头描述“大概发个位置速度”靠谱得多。要做验收或性能评估基本性能要求那一小节加附录 C是判断“这套东西到底行不行”的依据。要理解自家车为什么在某些情况下不报警或误报先看对应应用的主要场景往往能定位到是场景不成立还是判断阈值不合适。不必翻的几种情况。想学无线通信原理这份文件明确不管底层去读传输和接入层的材料更直接。想选型芯片、模组、天线这里没有器件参数只有数据格式。想解决单车感知问题摄像头和雷达的算法优化跟它无关它做的是“感知之外的信息补齐”。想看更高阶的协同驾驶或编队行驶注意副标题写着“第一阶段”17 个应用就是它的全部范围别指望在里面找到后面的东西。你手上的问题该去哪一部分这个应用在什么情况下该报警第 5 章对应应用的主要场景两个厂商的设备为什么对不上第 6 章数据集定义逐个字段核对我的应用要接不同厂商的硬件第 7 章 SPI 接口一览表验收时性能怎么算达标基本性能要求小节加规范性附录一期为什么选这 17 个应用资料性附录里的评选方法与需求分类底层用什么通信技术不在这里看下层规范有个习惯我用了很多年拿到任何一份这类文件先只读三处——范围、规范性引用文件、附录标注是“规范性”还是“资料性”。范围告诉你它管到哪儿为止引用文件告诉你它站在谁的肩膀上附录的标注告诉你哪些是真要求、哪些只是参考资料。这三页读完再决定要不要往下啃能省掉大把时间。早些年我反着来一头扎进数据集表格里逐行对照两天过去还没搞清这份文件到底管不管底层白折腾一场。从那以后每次都是先看这三页再决定翻不翻后面的几百页。需要对照原文细节的话完整的那份 PDF 就在资料里按上面这个顺序翻会比从头读到尾快得多。希望帮到你。本文还有配套的精品资源点击获取
