V2X是什么
参与V2X量产相关的项目于有一段时间了，终于终于现在对这个领域有了一个轮廓性的了解，真是不容易，功能虽小，但是将其用到量产，涉及到的知识却非常的广泛，趁着现在还没忘掉，打算沉淀成一篇笔记。
V2X，全称Vehicle-to-Everything，中文意思是“车对一切”。它是一种让车辆能够与周围环境中的各种实体进行数据交换的通信技术，是万物互联在汽车出行领域的拓展。这些实体包括：
- 其他车辆（V2V）：车辆之间可以互相通信，共享速度、位置、转向等信息，提前预警潜在的碰撞风险，提前做行驶规划，让车与车有了直接的交互。
- 行人（V2P）：车辆可以通过感知到附近的行人，尤其是盲区的行人非机动车，并采取相应的避让措施。
- 道路设施（V2I）：车辆可以直接与周边交通信号灯、路标等基础设施进行通信，获取实时准确的交通信息。
- 网络（V2N）：车辆可以连接到互联网，获取天气、路况以及更远处交通事故等信息等信息。
形象地说，常规的ADAS是给车辆装上了眼睛，让车辆自己可以观察周边环境进行一定程度的自动驾驶。而V2X就像给车辆装上了一张嘴巴和一对耳朵，可以说出自己的情况，以及听到周边车辆他们遇到的事情，这让更高级级别的自动驾驶成为可能。
V2X技术路线
目前，V2X主要有两大技术路线：DSRC和C-V2X：
- DSRC(IEEE 802.11p)技术：由IEEE主导标准制定，提供短距离无线传输技术，以车车和车路通信为主要方式。
- C-V2X技术：包括LTE-V2X和NR-V2X，由3GPP主导标准制定。C-V2X是将蜂窝通信技术和直通通信技术有机结合得车联网无线通信技术，同时支持车-车直通通信和蜂窝通信两种方式，支持车车、车路、车人以及车网等各类应用。
简单的说，对于车联网这个新的需求，尤其直通技术上，DSRC是将WiFi协议魔改过来得技术，而C-V2X是将无线通信LTE以及4G魔改来的技术。虽技术严谨路线有所区别，但是要解决的遇到的问题是大致一致的，IEEE 802.11p和C-V2X以及NR-V2X主要体现在无线接入技术的不同上。在协议其中C-V2X尽量重用蜂窝系统已有的上层协议，将研究重点聚焦于接入层的物理层和媒体接入技术。DSRC包括两类，用于ETC的DSRC和基于802.11pde DSRC，两者是不同的技术。两种技术路线相似的网络层可支持IP协议栈，同时考虑IP协议栈的开销以及低时延传输要求，，也可采用非IP传输支持上层应用。在《蜂窝车联网（C-V2X）》一书中有一个图表，很清晰对比出DSRC、LTE-V2X以及NR-V2X协议层的区别和联系。
适用范围和趋势
DSRC仅在部分早期部署国家（如日本、欧洲）保留残余应用，而LTE-V2X在中、美、韩等国已成主导技术。C-V2X（尤其是LTE/NR-V2X）凭借技术演进、政策支持和商业成熟度，将在不久的将来全面取代DSRC，成为智能交通和自动驾驶的核心通信标准。
关键技术标准
对于LTE-V2X有一个标准对其做出了总体技术要求：《YD_T 3400-2018 基于LTE的车联网无线通信技术 总体技术要求》，从很大范围的对其总体业务、系统架构以及功能需求做了一些规范性要求。比如说：有效通信距离、移动速度、通信时延、传输可靠性、覆盖要求、消息发送频率要求、消息大小要求、架构模型、接口、功能实体、高层功能、无线功能、标识以及功能描述和消息流等。
附录还有基于LTE车联网应用场景及需求部分，对于一些常见场景，可以了解其场景描述、预期效果和需求分析等内容。主要包含这些场景：
- 安全应用：
- 前方静止车辆告警
- 前方慢速车辆告警
- 紧急电子刹车灯告警
- 逆向超车提示
- 逆向行驶告警
- 换道决策辅助提示
- 交叉口防撞提示
- 异常车辆提示
- 道路危险状况提示
- 道路施工告警指示
- 协作式自动巡航控制
- 协作式高速公路车辆自动系统（直线）
- 前向碰撞预警
- 汇入主路辅助/碰撞告警
- 紧急车辆提示
- 非机动车横穿预警/行人横穿预警
- 道路湿滑/危险路段提醒
- 左转辅助/告警
- 闯红灯（/黄灯）告警
- 交通效率提升
- 道路限速提示
- 交通信号灯提醒
- 交通信息及路线推荐
- 增强得路线指引和导航
- 专用道路管理
- 限行管理
- 车载标识
- 车速引导
- 信息娱乐服务
- 服务信息公告
- 自动停车场入口
- 本地电子支付
- SOS/eCall业务
- 车辆被盗/损坏警报
- 车辆远程诊断，维修保养提示
物理层
LTE-V2X物理层主要参考的标准是《YD_T 3340-2018 基于LTE的车联网无线通信技术 空中接口技术要求》，主要包括PC5接口技术要求和Uu接口技术要求两部分。工作中没有用到太多这一层级的知识，故我也没做太过深入的研究。
网络层
LTE-V2X网络层主要参考的标准是《YD_T 3707-2020 基于LTE的车联网无线通信技术 网络层技术要求》，其框架如下图，支持Uu接口和PC5接口的接入层传输技术：
基于LTE的车联网无线通信技术网络层的数字子层包括TCP/UDP，IP， DSMP和适配层。适配层用于区分DSMP、IP、以及DME数据包，从而调用不同的接入层接口发送数据，以及将收到的数据传递给上层协议栈。适配层帧结构如下，包含帧头和Payload两部分。IP数据传输时无适配层帧头，适配层有效载荷用于封装上层数据包。适配层帧格式中的比特顺序为高位在前。目前标准中Protocol Type 为4表示DSMP，其余值为保留值。
在车联网C-V2X应用中我们更关注DSMP协议，下边截图时DSM逐层打包流程：
其中DSM的数据帧格式如下图，比特顺序为高位在前：
对于V2X应用开发来说，这决定了我们收到的数据对应的应用类型，以及选用哪一份ASN.1来解析数据段。AID采用变长字节表示，目前最多支持2个字节的表示，最少采用1个字节表示。目前标准中AID采用p-encoding的编码方式，其中具体的值，需要参考标准《YD/T 4008-2022引用基于LTE的车联网无线通信技术 应用标识分配及映射》。
| 字节0的最高位（x表示不关心）b7 b6 | AID 长度（字节） | AID 取值范围（采用p-encoding的十六进制） | AID取值范围 （十进制） | AID 取值范围（未采用p-encoding的十六进制） |
| 0 x | 1 | 0p00 到0p7F | 0到127 | 0x00 到0x7F |
| 1 0 | 2 | 0p80-00 到0pBF-FF | 128到16511 | 0x80 到0x40-7F |
| 1 1 | 长度≥3保留 | 保留 | 保留 | 保留 |
| 应用标识取值（十进制） | 应用标识取值（p-encoding的十六进制） | 字节长度 | 应用领域或其他描述 | 消息 | 映射的目标层二标识（十六进制） |
| 3616 | 0p8d.a0 | 2 | DSA发送 | DSA | 0x000000 |
| 111 | 0p6f | 1 | 车车基本安全应用-普通车辆状态 | BSM，常规 | 0x000001 |
| 112 | 0p70 | 1 | 车车基本安全应用-普通车辆关键事件提醒 | BSM，事件 | 0x000002 |
| 113 | 0p71 | 1 | 车车基本安全应用-紧急车辆状态 | BSM，常规 | 0x000003 |
| 114 | 0p72 | 1 | 车车基本安全应用-紧急车辆关键事件提醒 | BSM，事件 | 0x000004 |
| 3617 | 0p8d.a1 | 2 | 车车基本安全应用-后装车载终端 | BSM | 0x000005 |
| 3618 | 0p8d.a2 | 2 | 地图类应用 | MAP | 0x000006 |
| 3619 | 0p8d.a3 | 2 | 信号灯类应用 | SPAT | 0x000007 |
| 3620 | 0p8d.a4 | 2 | 道路信息-静态类应用 | RSI | 0x000008 |
| 3621 | 0p8d.a5 | 2 | 道路信息-半静态类应用 | RSI | 0x000009 |
| 3622 | 0p8d.a6 | 2 | 道路信息-动态类应用 | RSI | 0x00000A |
| 3623 | 0p8d.a7 | 2 | 道路提醒类应用 | RSM | 0x00000B |
| 3624 | 0p8d.a8 | 2 | 测试车辆发送 | 0x00000C | |
| 3625 | 0p8d.a9 | 2 | 测试路侧发送#1 | 0x00000D | |
| 3626 | 0p8d.aa | 2 | 测试路侧发送#2 | 0x00000E |
网络层中的Payload部分，即为应用层编码后的数据，其中与应用层数据是否签名是否加密会有些许区别，在介绍完下边几个层之后，我们来看一个编解码例子。
消息层
LTE-V2X消息层最基础的参考标准是《YD_T 3709-2020 基于LTE的车联网无线通信技术 消息层技术要求》,其标准化了消息层数据集的架构以及具体的数据定义和编码方式等。基于LTE的车联网无线通信技术消息层框架如下图：
消息层的标准主要目的是规范各家厂商在对于上一章节网络层中Payload（数据Data）的编码方式和编码内容，所有参与者使用同一规则编解码具体数据才能实现互联互通。其中在编码标准上，消息层数据集用ASN.1标准进行定义，遵循“消息帧-消息体-数据帧-数据元素”层层嵌套的逻辑进行指定。数据集交互的编解码方式遵循非对齐压缩码规则UPER。通常来讲各厂家使用同样内容的.asn文本文件，其定义了下文消息类型，然后使用成熟的ASN编解码库，就可以实现各自软件应用中数据的互联互通。
再具体一些，下文中提到的标准定义好的消息类型可以理解成程序中的数据结构体，这个结构体和.asn文件定义好的数据是一一对应的，然后ASN编解码库结合asn文件可以将数据结构体的内容编码成十六进制，然后通过C-V2X信道发送。接收端网络层接收到十六进制ASN编码后的数据口，通过ASN编解码库再解析成程序中的数据结构体，此时即回到了数据的明文形式，可以用于接下来的具体功能使用。当引入了证书签名，Payload部分需要进行一步额外的签名验签步骤，整体Payload会有所不同，后边有个例子。
对于C-V2X功能应用第一阶段场景（Day 1）开发来说，这个是最最需要经常翻阅以及了解的标准。其中详细描述了最经典的车车直连、这与路测单元直连所用消息类型：
- BSM (Basic Safety Message)： 基本安全消息，是最核心的消息类型，用于车辆广播自身的状态信息，如位置、速度、加速度、航向角等。其他车辆接收到BSM后，可以了解周围车辆的动态信息，从而实现安全预警和协作式驾驶。
- SPAT (Signal Phase and Timing Message)： 信号灯相位与定时消息，由路侧设备（RSU）发送，包含交通信号灯的相位信息和剩余时间。车辆接收到SPAT后，可以了解信号灯的状态，从而进行闯红灯预警、绿灯提前告知等应用。
- MAP (Map Data)： 地图数据消息，由路侧设备或云平台提供，包含道路的几何信息、车道线、交通标志等。车辆接收到MAP后，可以进行高精度定位、路径规划等应用。
- RSI (Roadside Safety Message)： 路侧安全消息，由路侧设备发送，用于广播道路安全事件信息，如交通事故、拥堵、施工等。车辆接收到RSI后，可以及时了解前方道路的交通状况，从而进行安全预警和路径调整。
- RSM (Road Safety Message)： 道路安全消息，用于车辆之间或车辆与路侧设备之间共享道路安全信息，例如车辆故障、紧急制动等。接收到RSM的车辆可以及时了解周围车辆的状况，从而进行安全预警。
- msgFrameExt：多用于第二阶段。
功能应用第二阶段场景（Day 2）开发来说，在《T_CSAE 157-2020合作式智能运输系统 车用通信系统应用层及应用数据交互标准（第二阶段）》标准中定义了一些新的消息类型：
- TEST： 该消息类型通常用于测试和调试C-V2X系统。它可以包含各种测试数据，以验证系统的功能和性能。
- RTCM (Radio Technical Commission for Maritime Services)： RTCM 消息主要用于提供高精度的定位信息，例如差分全球导航卫星系统 (DGNSS) 数据。这对于需要精确位置信息的应用非常重要，例如自动驾驶和车道级导航。
- RSC (Road Side Coordination)： RSC 消息用于路侧设备 (RSU) 之间的信息交换和协调。这有助于实现更智能的交通管理和控制，例如交通信号优化和道路事件通知。
- SSM (Station Status Message)： SSM 消息用于广播车辆或路侧设备的状态信息，例如位置、速度、方向等。这对于其他车辆和路侧设备了解周围环境非常重要，从而实现协作式驾驶和安全预警。
- VIR (Vehicle Information Request)： VIR 消息用于车辆之间请求和共享信息。例如，车辆可以请求其他车辆的位置、速度、加速度等信息，以支持协作式驾驶和安全应用。
- PAM (Platoon Announcement Message)： PAM 消息用于车辆编队 (platoon) 的创建和管理。它可以包含编队信息、车辆成员列表等。这对于实现车辆编队行驶和提高道路通行效率非常重要。
- PSM (Platoon Synchronization Message)： PSM 消息用于车辆编队中的车辆同步。它可以包含时间戳、位置信息等，以确保编队中的车辆保持同步行驶。
- CLPMM (Cooperative Lane Change Proposal Message)： CLPMM 消息用于车辆之间的协作式变道。车辆可以发送 CLPMM 消息，向其他车辆提议变道，并协调变道过程，以确保安全和效率。
- VPM (Vulnerable Pedestrian Message)： VPM 消息用于向车辆提供弱势交通参与者 (如行人、自行车) 的信息。这有助于提高道路安全，减少交通事故。
我将这些消息制作成了Mindmap，更加直观可以看数据结构的拓扑：
Pending
应用层
通常到了这一层，程序已经可以拿到具体的物理值形式的数据了，不同的厂商不同的车型，可以根据具体的需要，选择不同的数据处理方式以及将数据用于需要的场合。比如可以选择传统基于规则的方式，或者使用机器学期算法来进行安全预警或者辅助驾驶。甚至通过V2X采集来的数据，可以和ADAS相结合，将V2X技术当作一个传感器来使用，与其他数据源结合在一起来提供自动驾驶决策，也是非常有研究价值的课题。
为了给行业提供一个参考方向，中国汽车工程学会发布《T_CSAE 53-2020 合作式智能运输系统 车用通信系统 应用层及应用数据交互标准（第一阶段）》和《T_CSAE 157-2020合作式智能运输系统 车用通信系统应用层及应用数据交互标准（第二阶段）》两项标准，主要目的是推动智能网联汽车与车路协同技术的标准化发展，解决协同感知与安全应用中的关键问题，并促进产业生态的互联互通。两项标准作为团体标准，逐步向行业标准和国家标准过渡，为智能网联汽车测试、示范运营及法规制定提供技术依据。
第一阶段（T/CSAE 53-2020）定义了17个基础应用（或者说16个场景，部分业内人士对汽车进场支付场景认可度欠佳），通常行业中称之为Day 1 场景。第二阶段（T/CSAE 157-2020）扩展至12个高阶应用，行业中通常称之为Day 2 场景。
Day 1场景列表如下，标准中对于每个应用图文的形式介绍了应用定义和预期效果、主要场景、系统基本原理、通信方式、基本性能要求、数据交互需求等信息。其中主要用到的是BSM、MAP、SPaT、RSI、RSM信息，在标准的后半部分也又介绍了一遍对应的ASN.1定义，与YD_T 3709-2020中的消息类型定义一致。
| 序号 | 类别 | 主要通信方式 | 应用名称 |
| 1 | 安全 | V2V | 前向碰撞预警（FCW: Forward Collision Warning） |
| 2 | V2V/ V2I | 交叉路口碰撞预警（ICW: Intersection Collision Warning） | |
| 3 | V2V/ V2I | 左转辅助（LTA: Left Turn Assist） | |
| 4 | V2V | 盲区预警/变道预警（BSW/LCW：Blind Spot Warning/Lane Change Warning） | |
| 5 | V2V | 逆向超车预警（DNPW: Do Not Pass Warning） | |
| 6 | V2V-Event | 紧急制动预警（EBW: Emergency Brake Warning） | |
| 7 | V2V-Event | 异常车辆提醒（AVW: Abnormal Vehicle Warning） | |
| 8 | V2V-Event | 车辆失控预警（CLW：Control Loss Warning） | |
| 9 | V2I | 道路危险状况提示（HLW: Hazardous Location Warning） | |
| 10 | V2I | 限速预警（SLW: Speed Limit Warning） | |
| 11 | V2I | 闯红灯预警（RLVW: Red Light Violation Warning） | |
| 12 | V2P/ V2I | 弱势交通参与者碰撞预警（VRUCW: Vulnerable Road User Collision Warning） | |
| 13 | 效率 | V2I | 绿波车速引导（GLOSA: Green Light Optimal Speed Advisory） |
| 14 | V2I | 车内标牌（IVS: In-Vehicle Signage） | |
| 15 | V2I | 前方拥堵提醒（TJW: Traffic Jam Warning） | |
| 16 | V2V | 紧急车辆提醒（EVW: Emergency Vehicle Warning） | |
| 17 | 信息服务 | V2I | 汽车近场支付（VNFP, Vehicle Near-Field Payment） |
Day2场景列表如下，标准对每个场景从应用定义、预期效果、主要场景、系统基本原理、通信方式、基本性能要求、数据交换需求等方面做了介绍。同样，在这份标准的后半部分也介绍了一遍对应的ASN.1定义，在第一阶段消息集之外，主要介绍了对于MAP、RSI的拓展，以及9个msgFrameExt新的消息体。
| 序号 | DAY-II | 通信模式 | 触发方式 | 场景分类 | 主要消息 |
| 1 | 感知数据共享（SDS: Sensor Data Sharing） | V2V/V2I | Event | 安全 | Msg_SSM |
| 2 | 协作式变道（CLC: Cooperative Lane Change） | V2V/ V2I | Event | 安全 | Msg_VIR |
| 3 | 协作式车辆汇入（CVM: Cooperative Vehicle Merge） | V2I | Event | 安全/效率 | Msg_RSC Msg_VIR |
| 4 | 协作式交叉口通行（CIP: Cooperative Intersection Passing） | V2I | Event/Period | 安全/效率 | Msg_RSC |
| 5 | 差分数据服务（DDS: Differential Data Service） | V2I | Period | 信息服务 | Msg_RTCM |
| 6 | 动态车道管理（DLM: Dynamic Lane Management） | V2I | Event/Period | 效率/交通管理 | Msg_RSC |
| 7 | 协作式优先车辆通行（CHPVP: Cooperative High Priority Vehicle Passing） | V2I | Event | 效率 | Msg_VIR Msg_RSC |
| 8 | 场站路径引导服务（GSPA: Guidance Service in Parking Area） | V2I | Event/Period | 信息服务 | Msg_PAM Msg_VIR |
| 9 | 浮动车数据采集（PDC: Probe Data Collection） | V2I | Period/Event | 交通管理 | Msg_BSM Msg_VIR Msg_SSM |
| 10 | 弱势交通参与者安全通行（VRUSP: Vulnerable Road User Safe Passing） | P2X | Period | 安全 | Msg_PSM |
| 11 | 协作式车辆编队管理（CPM: Cooperative Platooning Management） | V2V | Event/Period | 高级智能驾驶 | Msg_CLPMM |
| 12 | 道路收费服务（RTS: Road Tolling Service） | V2I | Event/Period | 效率/信息服务 | Msg_VPM |
通信安全
知乎有两篇文章非常细致清晰的讲解了签名、加密、证书的基本原理以及在C-C2X中的应用：
https://zhuanlan.zhihu.com/p/59999022
https://zhuanlan.zhihu.com/p/391581956
总的来看，C-V2X技术遵循《YD_T 3957-2021 基于LTE的车联网无线通信技术 安全证书管理系统技术要求》标准使用证书对原始ASN编码后数据进行签名和验签，目前不涉及内容加密的环节，所以原始的ASN编码后的V2X数据是在证书签名后的数据中的一项，即unsecuredData。这里有一点需要注意的是原始V2X数据使用的是UPER编码协议进行的ASN.1编码，若需要安全签名，根据标准使用的是OER编码格式使用证书将前边UPER编码后的数据再次编码，然后整体作为DSMP层的Payload进行使用。
其他
还有很多其他的标准需要在V2X开发中需要去研读，比如说《基于LTE-V2X直连通信的车载信息交互系统技术要求及试验方法》，《GB_T 31024.1-2014 合作式智能运输系统 专用短程通信 第1部分：总体技术要求》，《GB_T 31024.2-2014 合作式智能运输系统 专用短程通信 第2部分：媒体访问控制层和物理层规范》，《GB_T 31024.3-2019合作式智能运输系统 专用短程通信 第3部分：网络层和应用层规范》，《GB_T 31024.4-2019合作式智能运输系统 专用短程通信 第4部分：设备应用规范》，《YD_T 3592-2019 基于LTE的车联网无线通信技术 基站设备技术要求》，《YD_T 3593-2019 基于LTE的车联网无线通信技术 核心网设备技术要求》，《YD_T 3594-2019 基于LTE的车联网通信安全技术要求》，《YD_T 3629-2020 基于LTE的车联网无线通信技术 基站设备测试方法》，《YD_T 3708-2020 基于LTE的车联网无线通信技术 网络层测试方法》，《YD_T 3710-2020 基于LTE的车联网无线通信技术 消息层测试方法》，《YD_T 3755-2020 基于LTE的车联网无线通信技术 支持直连通信的路侧设备技术要求》，《YD_T 3756-2020 基于LTE的车联网无线通信技术 支持直连通信的车载终端设备技术要求》，《YD_T 3847-2021 基于LTE的车联网无线通信技术 支持直连通信的路侧设备测试方法》，《YD_T 3848-2021 基于LTE的车联网无线通信技术 支持直连通信的车载终端设备测试方法》
ASN.1编解码
ASN.1
ASN.1 是 Abstract Syntax Notation One（抽象语法标记一）的缩写。ASN.1 允许描述复杂的数据结构，且独立于任何特定的编程语言。ASN.1 编译器会接收这些 ASN.1 规范，并生成一组目标语言（如 C、C++、Java）文件，这些文件包含这些抽象指定结构的原生类型定义，同时还会生成代码，用于将这些结构转换为字节序列（序列化）或从字节序列转换回结构（反序列化）。（通常，如果这些结构需要通过网络传输或写入外部介质，这些例程会非常有用。）
ASN.1 有多种数据编码方式，其中最广泛使用的包括：
- BER（基本编码规则，Basic Encoding Rules）
- CER（规范编码规则，Canonical Encoding Rules）
- DER（可辨别编码规则，Distinguished Encoding Rules）
- PER（压缩编码规则，Packed Encoding Rules）
- XER（XML 编码规则，XML Encoding Rules）
在中国，根据 YDT 3709-2020 标准，V2X 消息数据集遵循 非对齐压缩编码规则（UPER，Unaligned Packed Encoding Rules）。
编解码工具
常见开源库
asn1tools 和 asn1c 是用于 UPER 编码和解码的最广泛使用的开源库。
asn1c: https://lionet.info/asn1c/blog/
asn1tools: https://asn1tools.readthedocs.io/en/latest/
这两个工具分别由自己的优缺点：
asn1tools:
- 优点
- 生成的代码量较少。
- 仅生成 UPER 解码代码。
- 可执行文件体积较小。
- 计算速度更快。
- 缺点
- 不支持 ASN.1 符号中的所有类型。
asn1c
- 优点
- 支持 ASN.1 符号中的所有类型。
- 缺点
- 会生成所有编码规则的代码，因此代码量较大。
- 使用动态内存。
- 内存消耗会随时间增加，且无法立即释放内存。
进行编解码第一步是需要有定义好的ASN.1文件，如上边章节提到的，这些在C-V2X所涉及到的标准中，主要是在下列三项中定义的：
- YD_T 3709-2020 基于LTE的车联网无线通信技术 消息层技术要求
- T_CSAE 53-2020 合作式智能运输系统 车用通信系统 应用层及应用数据交互标准（第一阶段）
- T_CSAE 157-2020合作式智能运输系统 车用通信系统应用层及应用数据交互标准（第二阶段）
以BSM为例，我们将其中ASN.1代码以及所涉及到的所有层层应用，复制到一个文本文件，并定义成以asn结尾，再加上ASN标准需要用到的头部和尾部，即得到我们所需要的ASN编解码源文件。
我将使用Vector CANoe 配合Car2X插件以及Autotalks硬件来尝试编解码收发。Vector自己有个小工具可以将ASN.1数据转换成CANoe可以使用的数据库。
生成出来的数据库在应用层已经很完善了，可是在协议层可配置的数据不完整，我正在问Vector的客服，看看是怎么回事。在这儿我暂时先用了CANoe 17 示例工程里边的数据库，做一些学习。
无安全证书签名
通过CANoe with Car2X 插件发送了一个空的BSM消息，CANoe分层截图如下图：
从中可以看到，
完整收到的数据包时64 bytes原始数据是：
00 00 05 FF FF FF 04 04 00 6F 00 34 07 EF C0 00 00 00 00 00 00 00 BC 30 B3 E6 BD 02 96 58 5C AF 84 88 F0 80 80 80 00 FF D0 00 80 00 7E FF CF A1 FA 14 D7 FF FF E4 00 01 90 32 00 50 9F FF C0 00
C-V2X 数据链路层Payload：
04 04 00 6F 00 34 07 EF C0 00 00 00 00 00 00 00 BC 30 B3 E6 BD 02 96 58 5C AF 84 88 F0 80 00 FF D0 00 80 00 7E FF CF A1 FA 14 D7 FF FF E4 00 01 90 32 00 50 9F FF C0 00
C-V2X 层Payload：
04 00 6F 00 34 07 EF C0 00 00 00 00 00 00 00 BC 30 B3 E6 BD 02 96 58 5C AF 84 88 F0 80 80 80 00 FF D0 00 80 00 7E FF CF A1 FA 14 D7 FF FF E4 00 01 90 32 00 50 9F FF C0 00
适配层Payload：
00 6F 00 34 07 EF C0 00 00 00 00 00 00 00 BC 30 B3 E6 BD 02 96 58 5C AF 84 88 F0 80 80 80 D0 00 80 00 7E FF CF A1 FA 14 D7 FF FF E4 00 01 90 32 00 50 9F FF C0 00
DSMP 层Payload：
07 EF C0 00 00 00 00 00 00 00 BC 30 B3 E6 BD 02 96 58 5C AF 84 88 F0 80 80 80 00 FF D0 00 80 00 7E FF CF A1 FA 14 D7 FF FF E4 00 01 90 32 00 50 9F FF C0 00
我们着重于后边几层的解析，从中可以看到，适配层头部04代表DSMP协议，然后DSMP的头部00 6F 00 34代表DSMP使用版本为0的协议，消息类型是6F即 BSM（111），数据长度是00 34即52个字节。之后的52个字节即为BSM的ASN.1编码后数据，可以使用标准的ASN.1解码。可惜我使用我自己从标准中摘选出来的ASN.1并没有解析成功，不知道是否是因为和CANoe数据库有哪里不一致。有待查证。
有安全证书签名
然后我们用CANoe生成一个C-V2X证书，然后给给这个节点加上证书签名，证书信息如下图：
完整收到的数据包时原始数据是：
00 00 05 FF FF FF 04 04 00 6F 00 91 03 81 02 40 03 80 34 07 E8 80 00 00 00 00 00 00 00 B5 A9 F3 E6 BD 03 80 58 5C B0 07 88 DD 00 80 80 00 FF D0 01 40 00 7E FF CF A1 FA 14 D7 FF FF E4 00 01 90 32 00 50 9F FF C0 00 40 01 6F 00 02 5F 39 35 89 00 D8 80 E0 68 10 49 13 DC C5 97 84 40 35 62 E0 A3 6A C9 46 25 83 13 93 45 F2 88 51 2F 3F 4F 3A 38 53 F7 15 1E D3 C8 35 99 F9 B7 77 0C E1 FF E9 E7 8B C1 9F 7A 40 F6 C4 F2 AD 7D 69 BA 02 06 A9 F0 58 DC 23 3E 1E 27 EC 07 7F 7F 7C 92
C-V2X 数据链路层Payload:
04 04 00 6F 00 91 03 81 02 40 03 80 34 07 E8 80 00 00 00 00 00 00 00 B5 A9 F3 E6 BD 03 80 58 B0 07 88 DD 00 80 80 00 FF D0 01 40 00 7E FF CF A1 FA 14 D7 FF FF E4 00 01 90 32 00 50 9F FF C0 00 40 01 6F 00 02 5F 39 35 89 00 D8 80 E0 68 10 49 13 DC C5 97 84 40 35 62 E0 A3 6A C9 46 25 83 13 93 45 F2 88 51 2F 3F 4F 3A 38 53 F7 15 1E D3 C8 35 99 F9 B7 77 0C E1 FF E9 E7 8B C1 9F 7A 40 F6 C4 F2 AD 7D 69 BA 02 06 A9 F0 58 DC 23 3E 1E 27 EC 07 7F 7F 7C 92
C-V2X 层Payload ：
04 00 6F 00 91 03 81 02 40 03 80 34 07 E8 80 00 00 00 00 00 00 00 B5 A9 F3 E6 BD 03 80 58 5C B0 07 88 DD 00 80 80 00 FF D0 01 40 00 7E FF CF A1 FA 14 D7 FF FF E4 00 01 90 32 00 50 9F FF C0 00 40 01 6F 00 02 5F 39 35 89 00 D8 80 E0 68 10 49 13 DC C5 97 84 40 35 62 E0 A3 6A C9 46 25 83 13 93 45 F2 88 51 2F 3F 4F 3A 38 53 F7 15 1E D3 C8 35 99 F9 B7 77 0C E1 FF E9 E7 8B C1 9F 7A 40 F6 C4 F2 AD 7D 69 BA 02 06 A9 F0 58 DC 23 3E 1E 27 EC 07 7F 7F 7C 92
适配层Payload ：
00 6F 00 91 03 81 02 40 03 80 34 07 E8 80 00 00 00 00 00 00 00 B5 A9 F3 E6 BD 03 80 58 5C B0 07 88 DD 00 80 80 00 FF D0 01 40 00 7E FF CF A1 FA 14 D7 FF FF E4 00 01 90 32 00 50 9F FF C0 00 40 01 6F 00 02 5F 39 35 89 00 D8 80 E0 68 10 49 13 DC C5 97 84 40 35 62 E0 A3 6A C9 46 25 83 13 93 45 F2 88 51 2F 3F 4F 3A 38 53 F7 15 1E D3 C8 35 99 F9 B7 77 0C E1 FF E9 E7 8B C1 9F 7A 40 F6 C4 F2 AD 7D 69 BA 02 06 A9 F0 58 DC 23 3E 1E 27 EC 07 7F 7F 7C 92
DSMP 层Payload ：
03 81 02 40 03 80 34 07 E8 80 00 00 00 00 00 00 00 B5 A9 F3 E6 BD 03 80 58 5C B0 07 88 DD 00 80 80 00 FF D0 01 40 00 7E FF CF A1 FA 14 D7 FF FF E4 00 01 90 32 00 50 9F FF C0 00 40 01 6F 00 02 5F 39 35 89 00 D8 80 E0 68 10 49 13 DC C5 97 84 40 35 62 E0 A3 6A C9 46 25 83 13 93 45 F2 88 51 2F 3F 4F 3A 38 53 F7 15 1E D3 C8 35 99 F9 B7 77 0C E1 FF E9 E7 8B C1 9F 7A 40 F6 C4 F2 AD 7D 69 BA 02 06 A9 F0 58 DC 23 3E 1E 27 EC 07 7F 7F 7C 92
Unsecured data
07 E8 80 00 00 00 00 00 00 00 B5 A9 F3 E6 BD 03 80 58 5C B0 07 88 DD 00 80 80 00 FF D0 01 40 00 7E FF CF A1 FA 14 D7 FF FF E4 00 01 90 32 00 50 9F FF C0 00
我们着重于后边几层的解析，和没有证书签名的数据在应用层data之外的头部编码方式是类似的，从中可以看到，适配层头部04代表DSMP协议，然后DSMP的头部00 6F 00 91代表DSMP使用版本为0的协议，消息类型是6F即 BSM（111），数据长度是00 91即145个字节。之后的145个字节即为证书签名后的数据，签名流程按照《YD_T 3957-2021 基于LTE的车联网无线通信技术 安全证书管理系统技术要求》来进行，使用的OER编码格式。对于原始的BSM数据，是在签名后的数据中的一项：Unsecured data。可以使用网友的小工具解析这份前面数据：
https://const.net.cn/tool/v2x/asn-decode/
我们将DSMP 层Payload填入工具输入框，得到解析后的数据：
<V2XSecData-EncryptedSigned>
<protocolVersion>3</protocolVersion>
<content>
<signedData>
<hashId><sm3/></hashId>
<tbsData>
<payload>
<data>
<protocolVersion>3</protocolVersion>
<content>
<unsecuredData>
07 E8 80 00 00 00 00 00 00 00 B5 A9 F3 E6 BD 03
80 58 5C B0 07 88 DD 00 80 80 00 FF D0 01 40 00
7E FF CF A1 FA 14 D7 FF FF E4 00 01 90 32 00 50
9F FF C0 00
</unsecuredData>
</content>
</data>
</payload>
<headerInfo>
<aid>111</aid>
<generationTime>667649269367000</generationTime>
</headerInfo>
</tbsData>
<signer>
<digest>E0 68 10 49 13 DC C5 97</digest>
</signer>
<signature>
<sm2Signature>
<rSig>
35 62 E0 A3 6A C9 46 25 83 13 93 45 F2 88 51 2F
3F 4F 3A 38 53 F7 15 1E D3 C8 35 99 F9 B7 77 0C
</rSig>
<sSig>
E1 FF E9 E7 8B C1 9F 7A 40 F6 C4 F2 AD 7D 69 BA
02 06 A9 F0 58 DC 23 3E 1E 27 EC 07 7F 7F 7C 92
</sSig>
</sm2Signature>
</signature>
</signedData>
</content>
</V2XSecData-EncryptedSigned>
从中得到的unsecuredData再次使用ASN.1工具解码，即得到BSM明文。但是依旧我未成功通过自己的ASN.1解析出来，原因待分析。
应用场景、行业状态
C-NCAP
C-NCAP全称：China New Car Assessment Program（中国新车评价规程）和其他国家的NCAP（新车评价规程）是评估汽车安全性能的重要体系。C-NCAP由中国汽车技术研究中心（CATARC）制定，自2006年起实施，旨在通过标准化测试评估车辆的安全性能。测试内容包括正面碰撞、侧面碰撞、鞭打试验等，评估乘员保护、行人保护及安全辅助系统。评分体系采用五星制，五星为最高安全评级。C-NCAP每三年进行一次规程改版，当下有效是2024版本，2027正在制定中，多年来C-NCAP不断结合最新出现的技术和中国国情针对性地进行优化提升，走符合我国国情的汽车安全提升之路。
C-NCAP由中国汽车技术研究中心有限公司（CATARC）直接主导运营，是其核心业务之一，CATARC负责C-NCAP评价规程的制定和更新，结合中国道路实际需求调整测试项目，并通过C-NCAP与国际NCAP组织（如Global NCAP，E-NCAP）合作，促进标准接轨。C-V2X通过实时通信扩展了车辆的感知范围，可支持更复杂的主动安全功能，比如车辆高速直行与前方静止目标车辆测试场景CCRH（High Speed Car to Car Rear），车辆直行与前方被遮挡的横穿目标车辆测试场景C2C SCPO（Car-to-Car Straight Crossing Path with Obstruction）,交通信号识别系统TSR（Traffic Sign Recognition）以及弱势交通参与者保护VRU（Vulnerable Road User）。
C-V2X在C-NCAP中的作用主要体现在以下几个方面：
提高车辆感知能力： C-V2X技术可以通过V2V、V2I等通信，让车辆获取周围车辆、道路设施等信息，扩大车辆感知范围，提高感知精度。
实现更精准的预警和控制： C-V2X技术可以为车辆提供更及时、准确的预警信息，帮助驾驶员或自动驾驶系统做出更合理的决策，避免碰撞事故的发生。
提升复杂交通场景下的安全性： 在城市道路、高速公路等复杂交通场景下，C-V2X技术可以发挥重要作用，例如在盲区预警、变道辅助、交通拥堵预警等方面提供支持。
总结而言，C-V2X技术对C-NCAP的作用是多方面的，它不仅提高了C-NCAP的评估标准，促进了汽车安全技术的发展，还有助于改善道路交通安全，推动智能网联汽车的发展。随着C-V2X技术的不断成熟和应用，它将在C-NCAP中发挥越来越重要的作用。
详细的C-NCAP内容可以查阅官网：https://www.c-ncap.org.cn/ 以及当前有效的C-NCAP 2024的具体内容：https://www.c-ncap.org.cn/download 。目前2024版C-NCAP正式规程共有如下内容：
- C-NCAP管理规则（2024年版）
- 附录A 正面100%重叠刚性壁障碰撞试验规程
- 附录B 正面50%重叠移动渐进变形壁障（MPDB）碰撞试验规程
- 附录C 可变形移动壁障侧面碰撞试验规程
- 附录D 侧面柱碰撞试验规程
- 附录E 低速后碰撞颈部保护试验规程
- 附录F 儿童保护静态评价规程
- 附录G KNEE-MAPPING试验规程
- 附录H 侧面远端乘员保护规程
- 附录I 主被动离位乘员保护虚拟测评规程
- 附录J 乘员保护其他测评项
- 附录K VRU保护–头型&腿型试验规程
- 附录L 主动安全ADAS试验规程
- 附录M 整车灯光性能试验规程
- 附录N 电动汽车刮底试验规程
- 附录O VRU保护–AEB VRU测试规程
总结
随着智能交通系统的发展和自动驾驶技术的进步，V2X（Vehicle-to-Everything）技术正在成为提升交通安全与效率的关键。它通过让车辆与其他车辆、行人、道路基础设施以及互联网进行通信，大大扩展了车辆的感知范围，实现了更高级别的安全预警和驾驶辅助功能。
从技术路线来看，C-V2X凭借其优越的技术演进能力、政策支持和商业成熟度，已经逐渐取代DSRC，成为当前及未来车联网通信的主要标准。特别是LTE-V2X和NR-V2X，它们不仅支持车对车（V2V）、车对基础设施（V2I）、车对行人（V2P）的直接通信，还能够通过蜂窝网络实现车对网（V2N）的广泛连接，为用户提供更加丰富和实时的信息服务。
在实际应用场景中，C-V2X技术极大地提升了道路交通的安全性和效率。例如，在避免碰撞方面，无论是前方静止车辆告警还是逆向行驶告警等功能，都显著降低了交通事故的发生概率；而在提高交通效率上，如道路限速提示、交通信号灯提醒等应用，则帮助优化了交通流，减少了拥堵现象。
此外，C-V2X技术在推动智能网联汽车发展的同时，也促进了C-NCAP等汽车安全评估体系的进步。通过集成C-V2X技术，C-NCAP能够测试和评估车辆在复杂交通场景下的主动安全性能，从而推动整个汽车行业朝着更高的安全标准迈进。
总之，V2X技术不仅是实现完全自动驾驶的重要组成部分，也是构建智慧城市交通系统不可或缺的一环。随着相关技术的不断成熟和普及，我们有理由相信，未来的交通将更加安全、高效、便捷。
最后的最后，记录一下个人对于C-V2X技术栈的感受，在对C-V2X以及NR-V2X技术有了初步的了解够，感觉V2X技术中的V2N（Uu）想要真正利用起来应该是任重而又道远。当前基于传统的4G/5G网络云服务车联网通道已经可以满足绝大多数网联场景对于带宽和网络的需求，尤其是5G NR后空口延迟大大降低，进一步压缩了V2X技术V2N(Uu)通道的优势。有点像NB-IoT技术一样，虽然有低功耗、低成本等优势，但是考虑到覆盖率和稳定性兼容性等问题，多少年过去了推广范围还是比较有限，倒是4G的CAT1以及5G的RedCap目前感觉发展势头不错，个人也比较看好RedCap。对于V2X技术中的V2N(Uu)由于需要车端以及基站端的硬件软件支持，在技术复杂性以及成本方面有特别大的挑战，个人认为要走的路还有很远。对于直连的技术(PC5)比如V2V，V2I，V2P等，多数解决的场景使用其他的传感器也能一定程度上解决，比如雷达摄像头等。所以对于L2++以及以下的车型来说，尤其考虑到当前搭载V2X直连模组车型的市场覆盖率，很多OEM将其归为锦上添花的特性，将其视为ADAS的增强，配备于中高端车型中。在入门车型多数会由于成本控制原因而取消配备。个人认为当前V2X在市场中还处于非常早期的阶段，真正爆发将发生于市面上L3等级自动驾驶达到一定的普及率，当普通传感器解决了99%的问题，对于一些棘手的corner case可能就需要C-V2X的出场了。想要发展到L4或者L5级别的自动驾驶，当前单车智能路线一定是有其局限性的，届时基于V2X技术的车联网了一定是必备技术之一，那个时候应该就是V2X技术爆发的时刻，让我们拭目以待。
附录
CANoe解析不带证书签名的数据明文
Detail View
[-] Time
| 8.109317
| 0:00:00:08.109
[-] General
| Type: C-V2X Packet
| Radio Channel: 183
| Signal Strength: 40 dBm
| Signal Quality (SNR): —
| Packet Length: 64 bytes 40
| Direction: Tx
[-] Data
| Length 64 bytes
| 000h 00 00 05 FF FF FF 04 04 00 6F 00 34 07 EF C0 00 00 00 00 00 00 00 BC 30 B3 E6 BD 02 96 58 5C AF …ÿÿÿ…o.4.ïÀ…….¼0³æ½.–X\¯
| 020h 84 88 F0 80 80 80 00 FF D0 00 80 00 7E FF CF A1 FA 14 D7 FF FF E4 00 01 90 32 00 50 9F FF C0 00 „ˆð€€€.ÿÐ.€.~ÿÏ¡ú.×ÿÿä..2.PŸÿÀ.
[-] C-V2X Data Link Layer
| Source L2ID: 000005
| Destination L2ID: broadcast FFFFFF
[-] Payload
| Length 58 bytes
| 000h 04 04 00 6F 00 34 07 EF C0 00 00 00 00 00 00 00 BC 30 B3 E6 BD 02 96 58 5C AF 84 88 F0 80 80 80 …o.4.ïÀ…….¼0³æ½.–X\¯„ˆð€€€
| 020h 00 FF D0 00 80 00 7E FF CF A1 FA 14 D7 FF FF E4 00 01 90 32 00 50 9F FF C0 00 .ÿÐ.€.~ÿÏ¡ú.×ÿÿä..2.PŸÿÀ.
[-] C-V2X Layer
| Message Family: GB/T 31024.3 – Adaption Layer 04
[-] Payload
| Length 57 bytes
| 000h 04 00 6F 00 34 07 EF C0 00 00 00 00 00 00 00 BC 30 B3 E6 BD 02 96 58 5C AF 84 88 F0 80 80 80 00 ..o.4.ïÀ…….¼0³æ½.–X\¯„ˆð€€€.
| 020h FF D0 00 80 00 7E FF CF A1 FA 14 D7 FF FF E4 00 01 90 32 00 50 9F FF C0 00 ÿÐ.€.~ÿÏ¡ú.×ÿÿä..2.PŸÿÀ.
[-] Adaption Layer
| Protocol Type: DSMP 04
[-] Payload
| Length 56 bytes
| 000h 00 6F 00 34 07 EF C0 00 00 00 00 00 00 00 BC 30 B3 E6 BD 02 96 58 5C AF 84 88 F0 80 80 80 00 FF .o.4.ïÀ…….¼0³æ½.–X\¯„ˆð€€€.ÿ
| 020h D0 00 80 00 7E FF CF A1 FA 14 D7 FF FF E4 00 01 90 32 00 50 9F FF C0 00 Ð.€.~ÿÏ¡ú.×ÿÿä..2.PŸÿÀ.
[-] DSMP – DSRC Short Message Protocol
| Version: 0 00
| Option Indicator: 0 00
| Reserved: 0 00
[-] Application Identifier 111 6F
| Length: 1 bytes 0. . . . . . .
| Application Identifier: 111 . 110 1111
| Length: 52 bytes 0034
[-] Payload
| Length 52 bytes
| 000h 07 EF C0 00 00 00 00 00 00 00 BC 30 B3 E6 BD 02 96 58 5C AF 84 88 F0 80 80 80 00 FF D0 00 80 00 .ïÀ…….¼0³æ½.–X\¯„ˆð€€€.ÿÐ.€.
| 020h 7E FF CF A1 FA 14 D7 FF FF E4 00 01 90 32 00 50 9F FF C0 00 ~ÿÏ¡ú.×ÿÿä..2.PŸÿÀ.
[-] CSAE0053_MsgSet::BasicSafetyMessage
| frameType: bsmFrame 0
[-] bsmFrame
| msgCnt: 126 7E
| id: 00 00 00 00 00 00 00 05
| secMark: 57.733 s E185
| timeConfidence: time_000_000_000_000_01 27
[-] pos
| lat: 39.9842348 ° 17D51C2C
| lon: 116.4938506 ° 456F8D0A
| elevation: 48.1 m 1E1
[-] posAccuracy
| semiMajor: 0.05 m 1
| semiMinor: 0.05 m 1
| orientation: 0.0054932479 ° 1
[-] posConfidence
| pos: a1cm f
| elevation: elev_000_01 f
| transmission: forwardGears 2
| speed: 0.04 m/s 2
| heading: 0.0000 ° 0
| angle: 127 7F
[-] motionCfd
| speedCfd: prec0_01ms 7
| headingCfd: prec0_0125deg 7
| steerCfd: unavailable 0
[-] accelSet
| lon: 2001 7D1
| lat: 2001 7D1
| vert: -1.00 g CE
| yaw: 0.00 °/s 0
[-] brakes
| brakePadel: unavailable 0
[-] wheelBrakes unavailable 1000 0
| unavailable: 1 1 . . . .
| leftFront: 0 . 0 . . .
| leftRear: 0 . . 0 . .
| rightFront: 0 . . . 0 .
| rightRear: 0 . . . . 0
| traction: unavailable 0
| abs: unavailable 0
| scs: unavailable 0
| brakeBoost: unavailable 0
| auxBrakes: unavailable 0
[-] size
| width: 2.00 m C8
| length: 4.00 m 190
[-] vehicleClass
| classification: passenger_Vehicle_TypeUnknown A
[-] safetyExt
[-] pathPrediction
| radiusOfCurve: 32767 7FFF
| confidence: 0.0 % 0
CANoe解析带证书签名的数据明文
Detail View
[-] Time
| 12.513965
| 0:00:00:12.513
[-] General
| Type: C-V2X Packet
| Radio Channel: 183
| Signal Strength: 40 dBm
| Signal Quality (SNR): —
| Packet Length: 157 bytes 9D
| Direction: Tx
[-] Data
| Length 157 bytes
| 000h 00 00 05 FF FF FF 04 04 00 6F 00 91 03 81 02 40 03 80 34 07 E8 80 00 00 00 00 00 00 00 B5 A9 F3 …ÿÿÿ…o.‘..@.€4.者….µ©ó
| 020h E6 BD 03 80 58 5C B0 07 88 DD 00 80 80 00 FF D0 01 40 00 7E FF CF A1 FA 14 D7 FF FF E4 00 01 90 æ½.€X\°.ˆÝ.€€.ÿÐ.@.~ÿÏ¡ú.×ÿÿä..
| 040h 32 00 50 9F FF C0 00 40 01 6F 00 02 5F 39 35 89 00 D8 80 E0 68 10 49 13 DC C5 97 84 40 35 62 E0 2.PŸÿÀ[email protected].._95‰.Ø€àh.I.ÜÅ—„@5bà
| 060h A3 6A C9 46 25 83 13 93 45 F2 88 51 2F 3F 4F 3A 38 53 F7 15 1E D3 C8 35 99 F9 B7 77 0C E1 FF E9 £jÉF%ƒ.“EòˆQ/?O:8S÷..ÓÈ5™ù·w.áÿé
| 080h E7 8B C1 9F 7A 40 F6 C4 F2 AD 7D 69 BA 02 06 A9 F0 58 DC 23 3E 1E 27 EC 07 7F 7F 7C 92 ç‹ÁŸz@öÄò}iº..©ðXÜ#>.’ì.|’
[-] C-V2X Data Link Layer
| Source L2ID: 000005
| Destination L2ID: broadcast FFFFFF
[-] Payload
| Length 151 bytes
| 000h 04 04 00 6F 00 91 03 81 02 40 03 80 34 07 E8 80 00 00 00 00 00 00 00 B5 A9 F3 E6 BD 03 80 58 5C …o.‘..@.€4.者….µ©óæ½.€X\
| 020h B0 07 88 DD 00 80 80 00 FF D0 01 40 00 7E FF CF A1 FA 14 D7 FF FF E4 00 01 90 32 00 50 9F FF C0 °.ˆÝ.€€.ÿÐ.@.~ÿÏ¡ú.×ÿÿä..2.PŸÿÀ
| 040h 00 40 01 6F 00 02 5F 39 35 89 00 D8 80 E0 68 10 49 13 DC C5 97 84 40 35 62 E0 A3 6A C9 46 25 83 [email protected].._95‰.Ø€àh.I.ÜÅ—„@5bà£jÉF%ƒ
| 060h 13 93 45 F2 88 51 2F 3F 4F 3A 38 53 F7 15 1E D3 C8 35 99 F9 B7 77 0C E1 FF E9 E7 8B C1 9F 7A 40 .“EòˆQ/?O:8S÷..ÓÈ5™ù·w.áÿéç‹ÁŸz@
| 080h F6 C4 F2 AD 7D 69 BA 02 06 A9 F0 58 DC 23 3E 1E 27 EC 07 7F 7F 7C 92 öÄò}iº..©ðXÜ#>.’ì.|’
[-] C-V2X Layer
| Message Family: GB/T 31024.3 – Adaption Layer 04
[-] Payload
| Length 150 bytes
| 000h 04 00 6F 00 91 03 81 02 40 03 80 34 07 E8 80 00 00 00 00 00 00 00 B5 A9 F3 E6 BD 03 80 58 5C B0 ..o.‘..@.€4.者….µ©óæ½.€X\°
| 020h 07 88 DD 00 80 80 00 FF D0 01 40 00 7E FF CF A1 FA 14 D7 FF FF E4 00 01 90 32 00 50 9F FF C0 00 .ˆÝ.€€.ÿÐ.@.~ÿÏ¡ú.×ÿÿä..2.PŸÿÀ.
| 040h 40 01 6F 00 02 5F 39 35 89 00 D8 80 E0 68 10 49 13 DC C5 97 84 40 35 62 E0 A3 6A C9 46 25 83 13 @.o.._95‰.Ø€àh.I.ÜÅ—„@5bà£jÉF%ƒ.
| 060h 93 45 F2 88 51 2F 3F 4F 3A 38 53 F7 15 1E D3 C8 35 99 F9 B7 77 0C E1 FF E9 E7 8B C1 9F 7A 40 F6 “EòˆQ/?O:8S÷..ÓÈ5™ù·w.áÿéç‹ÁŸz@ö
| 080h C4 F2 AD 7D 69 BA 02 06 A9 F0 58 DC 23 3E 1E 27 EC 07 7F 7F 7C 92 Äò}iº..©ðXÜ#>.’ì.|’
[-] Adaption Layer
| Protocol Type: DSMP 04
[-] Payload
| Length 149 bytes
| 000h 00 6F 00 91 03 81 02 40 03 80 34 07 E8 80 00 00 00 00 00 00 00 B5 A9 F3 E6 BD 03 80 58 5C B0 07 .o.‘..@.€4.者….µ©óæ½.€X\°.
| 020h 88 DD 00 80 80 00 FF D0 01 40 00 7E FF CF A1 FA 14 D7 FF FF E4 00 01 90 32 00 50 9F FF C0 00 40 ˆÝ.€€.ÿÐ.@.~ÿÏ¡ú.×ÿÿä..2.PŸÿÀ.@
| 040h 01 6F 00 02 5F 39 35 89 00 D8 80 E0 68 10 49 13 DC C5 97 84 40 35 62 E0 A3 6A C9 46 25 83 13 93 .o.._95‰.Ø€àh.I.ÜÅ—„@5bà£jÉF%ƒ.“
| 060h 45 F2 88 51 2F 3F 4F 3A 38 53 F7 15 1E D3 C8 35 99 F9 B7 77 0C E1 FF E9 E7 8B C1 9F 7A 40 F6 C4 EòˆQ/?O:8S÷..ÓÈ5™ù·w.áÿéç‹ÁŸz@öÄ
| 080h F2 AD 7D 69 BA 02 06 A9 F0 58 DC 23 3E 1E 27 EC 07 7F 7F 7C 92 ò}iº..©ðXÜ#>.’ì.|’
[-] DSMP – DSRC Short Message Protocol
| Version: 0 00
| Option Indicator: 0 00
| Reserved: 0 00
[-] Application Identifier 111 6F
| Length: 1 bytes 0. . . . . . .
| Application Identifier: 111 . 110 1111
| Length: 145 bytes 0091
[-] Payload
| Length 145 bytes
| 000h 03 81 02 40 03 80 34 07 E8 80 00 00 00 00 00 00 00 B5 A9 F3 E6 BD 03 80 58 5C B0 07 88 DD 00 80 ..@.€4.者….µ©óæ½.€X\°.ˆÝ.€
| 020h 80 00 FF D0 01 40 00 7E FF CF A1 FA 14 D7 FF FF E4 00 01 90 32 00 50 9F FF C0 00 40 01 6F 00 02 €.ÿÐ.@.~ÿÏ¡ú.×ÿÿä..2.PŸÿÀ[email protected]..
| 040h 5F 39 35 89 00 D8 80 E0 68 10 49 13 DC C5 97 84 40 35 62 E0 A3 6A C9 46 25 83 13 93 45 F2 88 51 _95‰.Ø€àh.I.ÜÅ—„@5bà£jÉF%ƒ.“EòˆQ
| 060h 2F 3F 4F 3A 38 53 F7 15 1E D3 C8 35 99 F9 B7 77 0C E1 FF E9 E7 8B C1 9F 7A 40 F6 C4 F2 AD 7D 69 /?O:8S÷..ÓÈ5™ù·w.áÿéç‹ÁŸz@öÄò}i
| 080h BA 02 06 A9 F0 58 DC 23 3E 1E 27 EC 07 7F 7F 7C 92 º..©ðXÜ#>.’ì.|’
[-] V2X Sec – China V2X Security 2020
[-] Summary
| Protocol Version: 3
| Type: Signed data
| Generation Time: UTC+0 2025-02-26 10:07:44.367000
| AID: 111
| Signer Type: Digest (HashedId8)
| Signer Name: myCertificate
| Signer HashedId8: E0 68 10 49 13 DC C5 97
| Signature Status: Valid (Pseudonym Certificate trusted)
[-] Message Tree
| protocolVersion: 3 3
[-] content
[-] signedData
| hashId: sm3 2
[-] tbsData
[-] payload
[-] data
| protocolVersion: 3 3
[-] content
[-] unsecuredData
| Length 52 bytes
| 000h 07 E8 80 00 00 00 00 00 00 00 B5 A9 F3 E6 BD 03 80 58 5C B0 07 88 DD 00 80 80 00 FF D0 01 40 00 .者….µ©óæ½.€X\°.ˆÝ.€€.ÿÐ.@.
| 020h 7E FF CF A1 FA 14 D7 FF FF E4 00 01 90 32 00 50 9F FF C0 00 ~ÿÏ¡ú.×ÿÿä..2.PŸÿÀ.
[-] headerInfo
| aid: 111 6F
| generationTime: UTC+0 2025-02-26 10:07:44.367000 25F39358900D8
[-] signer
| digest: E0 68 10 49 13 DC C5 97 E0 68 10 49 13 DC C5 97
[-] signature
[-] sm2Signature
| rSig: 35 62 E0 A3 6A C9 46 25 83 13 93 45 F2 88 51 2F 3F 4F 3A 38 53 F7 15 1E D3 C8 35 99 F9 B7 77 0C 35 62 E0 A3 6A C9 46 25 83 13 93 45 F2 88 51 2F 3F 4F 3A 38 53 F7 15 1E D3 C8 35 99 F9 B7 77 0C
| sSig: E1 FF E9 E7 8B C1 9F 7A 40 F6 C4 F2 AD 7D 69 BA 02 06 A9 F0 58 DC 23 3E 1E 27 EC 07 7F 7F 7C 92 E1 FF E9 E7 8B C1 9F 7A 40 F6 C4 F2 AD 7D 69 BA 02 06 A9 F0 58 DC 23 3E 1E 27 EC 07 7F 7F 7C 92
[-] CSAE0053_MsgSet::BasicSafetyMessage
| frameType: bsmFrame 0
[-] bsmFrame
| msgCnt: 68 44
| id: 00 00 00 00 00 00 00 05 00 00 00 00 00 00 00 05
| secMark: 44.367 s AD4F
| timeConfidence: time_000_000_000_000_01 27
[-] pos
| lat: 39.9842816 ° 17D51E00
| lon: 116.4938768 ° 456F8E10
| elevation: 44.2 m 1BA
[-] posAccuracy
| semiMajor: 0.05 m 1
| semiMinor: 0.05 m 1
| orientation: 0.0054932479 ° 1
[-] posConfidence
| pos: a1cm f
| elevation: elev_000_01 f
| transmission: forwardGears 2
| speed: 0.10 m/s 5
| heading: 0.0000 ° 0
| angle: 127 7F
[-] motionCfd
| speedCfd: prec0_01ms 7
| headingCfd: prec0_0125deg 7
| steerCfd: unavailable 0
[-] accelSet
| lon: 2001 7D1
| lat: 2001 7D1
| vert: -1.00 g CE
| yaw: 0.00 °/s 0
[-] brakes
| brakePadel: unavailable 0
[-] wheelBrakes unavailable 1000 0
| unavailable: 1 1 . . . .
| leftFront: 0 . 0 . . .
| leftRear: 0 . . 0 . .
| rightFront: 0 . . . 0 .
| rightRear: 0 . . . . 0
| traction: unavailable 0
| abs: unavailable 0
| scs: unavailable 0
| brakeBoost: unavailable 0
| auxBrakes: unavailable 0
[-] size
| width: 2.00 m C8
| length: 4.00 m 190
[-] vehicleClass
| classification: passenger_Vehicle_TypeUnknown A
[-] safetyExt
[-] pathPrediction
| radiusOfCurve: 32767 7FFF
| confidence: 0.0 % 0