回复
合作式智能运输系统-车用通信系统应用层及应用数据交互标准 (下)
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
分类
赞
收藏
回复
相关推荐
