
合作式智能运输系统-车用通信系统应用层及应用数据交互标准 (下)
7 应用层数据交互标准及接口规范
7.1 应用层数据接口
应用层数据接口主要包括与系统应用对接的应用程序编程接口(API)和与不同通信设备对接的服务提供者接口(SPI)。其中应用程序编程接口(API)可以让不同的应用开发者独立开发能实现互联互通的应用,而无需担心使用的通信方式或者通信设备,也无需担心通信功能是通过调用本机驱动来实现,或者通过通信调用远程的通信模块来实现。服务提供者接口(SPI)可以实现车用通信系统与不同通信方式或者通信设备的兼容,并满足通信技术不断更新的需求。如图46所示。
7.2API接口
7.2.1AP1接口一览表
API接口一览见表21。
7.2.2API接口功能描述
7.2.2.1 AppGetHostInfo.request
应用层通过该原语获取本设备的数据请求,包括:
一一车辆。车辆的ID、车速、GNSS等基本属性:
一一基础设备。基础设施的功能,D等基本属性。
7.2.2.2 AppGetHostInfo.confirm
功能描述如下:
——接受请求:返回相关信息:
——拒绝请求:返回拒绝理由。
7.2.2.3 AppGetHostStatus.request
应用层通过该原语获取本设备的状态,包括:
——车辆,车身CAN通信、定位系统等状态信息;
——基础设施的状态。
7.2.2.4 AppGetHostStatus.confirm
功能描述如下:
——接受请求:返回相关信息
——拒绝请求:返回拒绝理由。
7.2.2.5 AppSetCommCfg.request
应用层通过该原语对底层通信参数进行配置,包括通信的模式、通道等参数。
7.2.2.6 AppSetCommCfg.confirm
功能描述如下:
——接受请求:返回相关信息;
——拒绝请求:返回拒绝理由。
7.2.2.7 AppGetCommStatus.request
应用层通过该原语获取底层通信状态属性及状态信息请求,包括通信类型、参数、性能属性等。
7.2.2.8 AppGetCommStatus.confirm
功能描述如下:
——接受请求:返回相关信息;
——拒绝请求:返回拒绝理由。
7.2.2.9 AppDSMInit.request
应用层通过该原语进行DSM消息初始化请求,设置通道,发送、接收参数等。
7.2.2.10 AppDSMInit.confrim
功能描述如下:
——接受请求:允许DSM数据发送与接收,并成功配置参数;
——拒绝请求:返回拒绝理由。
7.2.2.11 AppDSMTerminate.request
应用层通过该原语请求DSM消息终止服务。
7.2.2.12 AppDSMTerminate.request
功能描述如下:
——接受请求:终止DSM数据发送与接收;
——拒绝请求:返回拒绝理由。
7.2.2.13 AppSendDSMMsg.request
应用层通过该原语进行DSM消息发送请求。
7.2.2.14 AppSendDSMMsg.confirm
功能描述如下:
——接受请求:发送成功
——拒绝请求:发送失败,失败理由。
7.2.2.15 AppDupBSM.request
应用层通过该原语请求直接访问BSM消息,可以配置查询方式或者中断方式。
7.2.2.16 AppDupBSM.confrim
功能描述如下:
——接受请求:返回镜像BSM消息到上层应用;
——拒绝请求:返回拒绝理由。
7.2.2.17 AppDupBSM.indication
BSM消息通知到上层应用,BSM消息内容参照应用层标准。
7.2.2.18 AppDupMap.request
应用层通过该原语请求直接访问MAP消息,可以配置查询方式或者中断方式。
7.2.2.19 AppDupMAP.confr im
功能描述如下:
——接受请求:返回镜像MAP消息到上层应用;
——拒绝请求:返回拒绝理由。
7.2.2.20 AppDupMAP.indication
MAP消息通知到上层应用,MAP消息内容参照应用层标准。
7.2.2.21 AppDupSPAT.request
应用层通过该原语请求直接访问SPAT消息,可以配置查询方式或者中断方式。
7.2.2.22 AppDupSPAT.confr im
功能描述如下:
——接受请求:返回镜像SPAT消息到上层应用;
——拒绝请求:返回拒绝理由。
7.2.2.23 AppDupSPAT.indi cation
SPAT消息通知到上层应用,SPAT消息内容参照应用层标准。
7.2.2.24 AppDupRSM.request
应用层通过该原语请求直接访问RSM消息,可以配置查询方式或者中断方式。
7.2.2.25 AppDupRSM.confrim
功能描述如下:
——接受请求:返回镜像RSM消息到上层应用:
——拒绝请求:返回拒绝理由。
7.2.2.26 AppDupRSM.indication
RSM消息通知到上层应用,RSM消息内容参照应用层标准。
7.2.2.27 AppGetTC.request
应用层通过该原语请求访问TC服务中的车辆信息,可以配置查询方式或者中断方式获取TC中的车辆
信息,可以指定一个或者多个TC区域。
7.2.2.28 AppGetTC.confirm
功能描述如下:
——接受请求:返回相应TC区域的车辆信息;
——拒绝请求:返回拒绝理由。
7.2.2.29 AppGetTC.indication
指定TC有更新车辆时,返回信息到应用层。
7.2.2.30 AppGetRemoteVehicles.request
应用层通过该原语以指定车辆ID的方式请求指定一个或者一组车辆的BSM信息。
7.2.2.31 AppGetRemoteVehicles.confirm
功能描述如下:
——接受请求:返回指定车辆详细信息确认;
——拒绝请求:返回拒绝理由。
7.2.2.32 AppGetRemoteVehicles.indication
指定车辆信息BSM有更新时通知到上层应用。
7.2.2.33 AppGetEventVehicle.request
应用层通过该原语请求访问周边的事件车辆,可以配置查询方式或者中断方式访问一种或者多种事件或状态,事件车辆包括紧急刹车、异常车辆、失控车辆等特殊事件激活或者救护车、警车等特殊状态激活的车辆。
7.2.2.34 AppGetEventVehicle.confirm
功能描述如下:
——接受请求:返回应用层事件车辆信息;
——拒绝请求:返回拒绝理由。
7.2.2.35 AppGetEventVehicle.indication
当接收到远端车辆具有指定事件或者状态时,返回相关信息于上层应用。
7.2.2.36 AppRoadSideAlert.request
应用层通过该原语请求访问周边指定的路侧警示信息,可以配置查询方式或者中断方式。
7.2.2.37 AppRoadSideAlert.confirm
功能描述如下:
——接受请求:返回上层应用路侧单元警告消息;
一一拒绝请求:返回拒绝理由。
7.2.2.38 AppRoadSideAlert.indication
路侧单元警示消息有更新时通知上层应用。
7.2.2.39 AppSignal.request
应用层通过该原语请求访问周边指定的信号灯信息,可以配置查询方式或者中断方式。
7.2.2.40 AppSignal.confirm
功能描述如下:
——接受请求:返回信号灯状态信息:
——拒绝请求:返回决绝理由。
7.2.2.41 AppSignal.indication
信号灯信息有更新时通知应用层。
7.2.2.42 AppPedestrian.request
应用层通过该原语请求访问周边的行人信息,可以配置查询方式或者中断方式。
7.2.2.43 AppPedestrian.confirm
功能描述如下:
——接受请求:返回行人相关信息;
——拒绝请求:返回拒绝理由。
7.2.2.44 AppPedestr ian.indication
行人信息有更新时通知应用层。
7.2.2.45 AppGetServices.request
该原语表明上层请求获取当前设备所有服务列表详细信息。接收后,ADS产生AppGetServices…confirm,表明请求是否被接受。
7.2.2.46 AppGetServices.confirm
该原语确定接收到上层对应的请求,用于回应AppGetService.request。如果接受请求,返回请求的相关详细信息;如果拒绝请求,则返回拒绝理由。
7.2.2.47 AppProviderService.request
该原语表明上层对Provider服务的操作请求。接受后ADS产生AppProviderService…confirm,表明请求是否被接收。
7.2.2.48 AppProviderService.confirm
该原语确定接收到上层对应的请求,用于回应AppProviderService.request。如果接受请求,则执行对应的操作,并返回操作结果;如果拒绝请求,则返回拒绝理由。
7.2.2.49 AppUserService.request
该原语表明上层对User服务的操作请求。接受后ADS产生AppUserService.confirm,表明请求是否被接收。
7.2.2.50 AppUserService.confirm
该原语确定接收到上层对应的请求,用于回应AppUserService.request。如果接受请求,则执行对应的操作,并返回操作结果;如果拒绝请求,则返回拒绝理由。
7.2.2.51 AppPayment.request
该原语表明上层对支付操作的请求,接受后产生AppPayment…confirm,表明请求是否被接收。
7.2.2.52 AppPayment.conf irm
该原语确定接收到上层对应的请求,用于回应AppPayment.request。如果接受请求,则执行对应的操作;如果拒绝请求,则返回拒绝理由。
7.3SP1接口
7.3.1SP1接口一览表
SPI接口一览见表22。
7.3.2SP1接口功能描述
7.3.2.1 CommClientInit.request
该原语表明上层请求进行对应消息类型的发送初始化操作,接收后,产生CommClientInit.confirm,表明是否被接受。
7.3.2.2 CommClientInit.confirm
该原语表明接收上层对应的请求,用于回应CommClientInit.request。如果接受请求,则返回初始化之后的相关信息;如果拒绝请求,则返回拒绝理由。
7.3.2.3 CommDSMSend.request
该原语表明上层请求进行DSM消息发送请求,接收后,产生CommSDMSend.confirm,表明是否被接受。
7.3.2.4 CommDSMSend.confirm
该原语表明接收上层对应的请求,用于回应CommDSMSend.request,并返回对应请求结果。
7.3.2.5 CommDSM.indication
该原语用于底层向上层提交DSM消息。
7.3.2.6 CommDMESetCfg.request
该原语表明上层请求设置DME请求,接收后,产生CommDMESetCfg.confirm。
7.3.2.7 CommDMESetCfg.confirm
该原语表明接收上层对应的请求,用于回应CommDMESetCfg.request,如果接受,并返回对应请求结果;如果决绝,则返回决绝理由。
7.3.2.8 CommDMEGetCfg.request
该原语表明上层请求获取DME请求,接收后,产生CommDMEGetCfg.confirm,表明操作结果。
7.3.2.9 CommDMEGetCfg.confirm
该原语表明接收上层对应的请求,用于回应CommDMEGetCfg.request,如果接受,并返回对应请求结果;如果拒绝,则返回拒绝理由。
7.3.2.10 CommDMEProviderService.reuqest
该原语表明上层对DME Provider服务的操作请求。接收后,产生CommDMEProviderService.confirm,表明操作结果。
7.3.2.11 CommDMEProviderService.confirm
该原语表明接收上层对应的请求,用于回应CommDMEProviderService.request。如果接受,则执行对应操作,并返回操作结果;如果拒绝,则返回拒绝理由。
7.3.2.12 CommDMEUserService.request
该原语表明上层对DME User服务的操作请求。接收后,产生CommDMEUserService.confirm,表明操作结果。
7.3.2.13 CommDMEUserService.confirm
该原语表明接收上层对应的请求,用于回应CommDMEUserService…request。如果接受,则执行对应操作,并返回操作结果;如果拒绝,则返回拒绝理由。
7.3.2.14 CommDMENot ification.indication
该原语用于底层向上层提交DME通知。
附录A(资料性)一期应用评选方法
本文件一期应用的选择,采用工作组内部征集和投票的方式。首先在工作组内部征集典型V2X应用,再由工作组各成员对征集的应用进行投票,最后根据各个应用得票数确定一期应用。
共有20家工作组成员单位参与了一期应用的征集和评选,这20家单位的行业领域分布如下:
——汽车制造商(OEM):5
——研究机构:5
——高校:2
——通信企业:3
——ITS设备及解决方案供应商:2
——数据服务商:2
——金融机构:1
首先,在工作组内进行应用征集,共统计出40个典型V2X应用,涵盖安全、效率、信息服务三大类,其中安全类19个,效率类12个,信息服务类9个。然后由20家成员单位从技术成熟度、应用价值及近期可实现性三个维度,对40个V2X应用进行投票,每个成员限投15个。最后根据得票数,并综合考虑应用的典型性,确定17个一期应用,其中安全类12个,效率类4个,信息服务类1个。具体应用征集和投票结果见表A.1。
附录B(资料性)一期应用按通信需求分类表
根据应用对通信频率和时延的不同需求将17个一期应用分为两大类:一是高时延(>100ms)、低频率(<10Hz)的应用,可通过4G蜂窝通信技术实现;二是低时延(≤100ms)、高频率(≥10Hz)的应用,需要LTE-V2X、DSRC或5G通信技术的支持才能实现。见表B.1。
附录C(规范性)前向碰撞预警(FCW)基本性能指标依据
C.1FCW交互流程
FCW交互流程如表C.1。
C.2指标依据说明
基本性能指标依据如下:
——数据更新频率、系统延迟参照J2735、J2945及NHTSA VSC-A性能指标说明:
——通信距离≥300m;
采用车辆间最小安全距离模型,说明车辆制动过程如图C.1所示。
根据汽车制动动力学,最小安全距离模型如下:
假设两车间的速度差为100km/h,驾驶员反应时间为2s,车辆制动安全的加速度大小为取值为3.6m/s2;则最小安全距离为182m。这是在考虑两车速度相差比较大及驾驶员反应比较慢的情况下,因此通信距离300m足够满足碰撞预警的要求定位精度≤1.5m。
前向碰撞预警需筛选出位于“前方同车道”区域的远车(V),涉及同一车道的判断。中国车道宽度为(2.753.5)m,取车道宽为3.5m。
假设自车(HV)在车道的中间行使,以车头位置的横纵坐标为基准:横向左右1.75m以内,HV之前的,称为前向(Ahead);横向左右1.75m,HV之后的,称为后向(Behind)。
基于上述需求,GSS定位精度需要满足1.5m的要求。
原文作者:爱是与世界平行
原文链接:https://blog.51cto.com/lovebetterworld/5777206
