以车用通信系统中的车载单元OBU为例说明该该系统的架构

最近解读了一份CSAE（Chinese Society of Automotive Engineering，中国汽车工程学会，对照SAE美国汽车工程师学会）关于V2X的标准，《合作式智能运输系统 车用通信系统应用层及应用数据交互标准》（TCSAE 53-2017），觉得蛮有意思，类似于那种...突然之间有了灵感，特意爬上来跟大家分享下。

前言中标准的支持单位中我有注意到，最后一位是“乐视汽车（北京）有限公司”，虽然贾老板账目做的六，至少V2X这块还是有不少IP的。

该标准主要参考引用了美标中《SAE J2735专用短程通信消息集字典（Dedicated Short Range Communications(DRSC) Message Set Dictionary）》以及《SAE J2945/1 V2V车载安全通信系统性能需求（On-Board System Requirement for V2V Safety Communications）》两份，其他的没了，所以...你们懂的~

标准中以车用通信系统中的车载单元OBU为例说明该系统的架构。车载设备通常包括了以下子系统：

无线电通信子系统：接收和发送空中信号

定位系统：通常包含全球导航微信系统（GNSS，globalnavigationsatellitesystem）接收器，用以提供车辆的位置、方向、速度和时间等信息

车载设备处理单元：运行程序以生成需要发送的空中信号，以及处理接收的空中信号

天线：实现射频信号的接收和发送

架构与T-BOX相差无几，很容易理解其组成单元。

标准定义了合作市智能交通系统车用通信系统基础应用及基本要求，定义了应用层数据集字典、数据交换标准及接口规范。注意这个地方实际说清楚了标准范围，参考通信系统七层模型，示意如下：

接下来是非常重要的一张表，17个典型「一期」应用，涵盖安全、效率、信息服务。

其中，

V2V：车载单元之间通讯，Vehicle to Vehicle

V2I：车载单元与路侧单元通讯，Vehicle to Infratructure

V2P：车载单元与行人设备通讯，Vehicle to Pedestrains

为了方便索引，列举如下：

前向碰撞预警Forward Collision Warning/FCW

交叉路口碰撞预警Intersection Collision Warning/ICW

左转辅助Left turning Assistant/LTA

盲区预警/变道预警Blind Spot Warning/BSW、Lane Change Warning/LCW

逆向超车预警Do Not Pass Warning/DNPW

紧急制动预警Emergency Brake Warning/EBW

异常车辆提醒Abnormal Vehicle Warning/AVW

车辆失控预警Control Loss Warning/CLW

道路危险状况提示Hazardous Location Warning/HLW

限速预警Speed Limit Warning/SLW

闯红灯预警Red Light Violation Warning//RLVW

弱势交通参与者碰撞预警Vulnerable Road User Collision Warning/VRUCW

绿波车速导引Green Light Optimal Speed Advisory/GLOSA

车内标牌In-Vehicle Signage/IVS

前方拥堵提醒Traffic Jam Warning/TJM

紧急车辆提醒Emergency Vehicle Warning/EVW

汽车近场支付Vehicle Near-Field Payment/VNFP

然后从应用定义、主要场景、系统基本原理、通信方式、基本性能要求和数据交互需求对17个一期应用分别进行了描述。我们就挑选第一个，前向碰撞预警Forward Collision Warning/FCW，简单说明下。

应用定义不说了，对辅助驾驶了解的都应比较清楚；主要场景可参考下述图示。

get到了嘛？「在驾驶员还参与驾驶过程情况下，上述场景的应用几乎全都是鸡肋」。唯一一个有想象空间的RV-1/RV-2（RV：远车，Remote Vehicle）在标准还未统一、理念还未普及的情况下就是一个空中楼阁啊。

中间的几项跳过去我们再看下“基本性能要求”：

主车车速范围0~130km/h;

通信距离≥300m；

数据更新频率小于等于10Hz；

系统延迟≤100ms；

定位精度≤1.5m。

除了“定位精度”其他的要求可以说低到尘埃了，定位精度1.5m的要求是为了识别主车道与相邻车道。

“数据交互需求”详见下表：

几乎都是对新增定位系统以及惯导单元的要求，当前的汽车架构能满足个50%顶天了（时刻、尺寸、速度、两轴加速度、横摆角速度）。

接下来标准对应用层交互数据集进行了定义。需要注意的是，V2X中的数据通讯大多采用广播的方式（少部分事件触发），所以这块并未按照17个场景进行划分而是直接针对5个最基本的消息体进行了定义：

Msg_BSM，Basic Safety Message/车辆基本安全消息；车辆之间交换安全状态数据；

Msg_MAP，地图消息，由路侧单元广播，向车辆传递局部区域的地图信息。包括局部区域的路口信息、路段信息、车道信息，道路之间的连接关系等；

Msg_RSI，由路侧单元项周围车载单元发布的交通时间消息以及交通标志牌信息；

Msg_RSM，路侧安全消息。路侧单元通过路侧本身拥有的相应检测手段，得到其周边交通参与者的实时状态信息（包括路侧单元本身、周围车辆、非机动车、行人等），并将这些信息整理成本消息体所定义的格式，作为这些交通参与者的基本安全状态信息，广播给周边车辆，支持这些车辆的相关应用；

Msg_SPAT，信号灯消息。包含一个或多个路口信号灯的当前状态信息。结合MAP消息，为车辆提供实时的前方信号灯相位信息。

同样，我们拿第一个消息体Msg_BSM按照“消息集-数据帧-数据元素”的形式展开，其数据帧构成如下（我关心应用层，具体格式做了舍弃处理）：

MsgCount

vehicle ID

Reserved for Electronic Vehicle Identification（OPTIONAL）

DSecond

PositionED

PositionConfidenceSet

TranmissionState

Speed

Heading

SteeringWheelAngle（OPTIONAL）

MotionConfidenceSet（OPTIONAL）

AccelerationSet4Way

BrakeSystemStatus

VehicleSize

VehicleClassification

VehicleExtensions（OPTIONAL）

取其中BrakeSystemStatus为例，其数据元素构成如下：

brakePadel：刹车踏板踩下情况；

wheelBrakes：车辆车轮制动情况；

traction：牵引力控制系统作用情况；

abs：制动防抱死系统作用情况；

scs：车身稳定控制系统作用情况；

brakeBoost：刹车助力系统作用情况；

auxBrakes：辅助制动系统（一般指手刹）情况。

然后针对数据元素DE_BrakePadelStatus进行了信号级别的定义，

0x00:UNAVAILABLE--vehicle brake padel detector is unavailable

0x01:OFF--vehicle's brake padel is not pressed

0x02:ON--vehicle's brake padel is pressed

至此，则完成了“应用层交互数据集”的定义。事实上，与传统车载总线的信号矩阵框架类似，对车载总线了解的朋友应该很容易理解。

完成解读之后，我个人的感觉如下：

当前来看，应用场景太鸡肋；

国内法规标准不健全，普及道路漫长。

后来与业内朋友沟通，也将他们的观点列举如下（认同部分观点）：

国内目前没有统一、成体系的标准或者协议，美国有全套DSRC相关的，这也是为什么2017年凯迪拉克在量产车型CTS上配备V2X；

目前通信距离能够做到300m~1000m，时延能够做到十几毫秒内；

两个典型的V2X使用案例，一个是交叉路口遮挡的情况，一个是连环相撞的情况。

对了，这位朋友在一家聚焦无人货运的公司搞V2X。