车联网服务信息下发方法和服务器、路侧设备以及系统

技术领域

本申请涉及车联网技术领域，尤其涉及车联网服务信息下发方法和服务器、路侧设备以及系统。

背景技术

随着数字货币的发展，数字货币与V2X共享消息交互结合的场景得到应用，但是目前对于车辆道路方面的数字支付场景的交互仍然存在难点，因此需要道路上的辅助设施通过V2X(vehicle to everything，车用无线通信技术)通信的手段实现对环境的检测和通知，以辅助车辆更安全的驾驶。

目前V2X仅仅能够进行路侧设备与车辆的简单交互，仅能够将预设的信息下发给车载终端，而无法进行进一步的数据交互操作，更无法结合数字货币技术进行复杂数据交互，因此存在诸多不足。

发明内容

本申请实施例提供了车联网服务信息下发方法和服务器、路侧设备以及系统，用于解决目前V2X仅仅能够进行路侧设备与车辆的简单交互，仅能够将预设的信息下发给车载终端，而无法进行进一步的数据交互操作，更无法结合数字货币技术进行复杂数据交互的问题。

为解决上述技术问题，本申请实施例提供以下技术方案：

本申请第一方面实施例提供一种车联网服务信息下发方法，由云端服务器执行，包括：

根据车联网状态信息生成每个路侧设备覆盖范围内至少一个车辆的待下发服务信息；所述车联网状态信息包括：每个路侧设备标识以及每个路侧设备覆盖范围内的车辆信息；将每个待下发服务信息发送至对应的路侧设备，以使各路侧设备将接收的每个待下发服务信息发送至对应车辆；接收各路侧设备发送的服务支付请求，执行服务支付操作，以使车载终端兑现所述待下发服务中的服务内容，其中所述服务支付请求是车载终端请求购置所述待下发服务信息中的服务内容而生成，并由对应的路侧设备接收得到。本申请实施例中通过根据车联网状态信息确定出对应车辆的待下发服务信息，例如服务公告，之后将服务信息发送给路侧设备，路侧设备通过广播或者定点传输给覆盖范围内的车载终端，车载终端因此即接收到服务公告，之后根据自身需要对服务公告中的服务进行支付，从而本申请结合了数字货币和V2X共享消息两者配合，形成了车辆可以在每个服务场景下选择购买服务，即可当即享受到服务效果，提升了驾驶员的道路行驶体验。

在一种可能的实施方式中，所述根据每个路侧设备标识以及每个路侧设备覆盖范围内的车辆信息，生成每个路侧设备覆盖范围内至少一个车辆的待下发服务信息，包括：

根据每个路侧设备标识查找预设的路侧设备标识与服务信息的对应关系，得到每个路侧设备对应的服务信息；

获取每个路侧设备覆盖范围内所有车辆的账户信息，并根据所述账户信息查找每个车辆的已购置服务信息；

根据每个路侧设备对应的服务信息以及对应的覆盖范围内每个车辆的已购置服务信息，确定每个车辆的所述待下发服务信息。

本实施例中示出了具体的待下发服务信息的生成过程，从而可以根据路侧设备的的标识进行服务下发，路侧设备根据自身的场景需求以及资源配置在云端服务器注册对应的服务，云端服务器可以根据对应的标识进行服务的下发，并且配合路侧设备对每个车辆已购置服务进行信息提取，从而避免了重复推送导致用户体验感下降的问题。

在一种可能的实施方式中，所述车联网状态信息还包括：道路信息，相对应地，所述根据车联网状态信息生成每个路侧设备覆盖范围内至少一个车辆的待下发服务信息，包括：

根据每个路侧设备标识、道路信息以及每个路侧设备覆盖范围内的车辆信息，生成每个路侧设备覆盖范围内至少一个车辆的待下发服务信息。

本实施例进一步结合道路信息进行待下发服务信息的推送，从而可以考虑道路突发状况，例如道路出现车祸、堵车或者公共设施损坏等，均可以精准地给出服务推荐，进一步提高用户体验。

在一种可能的实施方式中，根据每个路侧设备标识、道路信息以及每个路侧设备覆盖范围内的车辆信息，生成每个路侧设备覆盖范围内至少一个车辆的待下发服务信息，包括：

根据每个路侧设备所处的道路信息确定服务场景类型；

根据所述服务场景类型，结合预设的服务场景类型和服务信息的对应关系，确定每个路侧设备对应的服务信息；

获取每个路侧设备覆盖范围内所有车辆的账户信息，并根据所述账户信息查找每个车辆的已购置服务信息；

根据每个路侧设备对应的服务信息以及对应的覆盖范围内每个车辆的已购置服务信息，确定每个车辆的所述待下发服务信息。

本实施例中每种道路可能存在近似的道路状况，因此结合道路类型可以大致得到类似的道路状况，而类似的道路状况大多数的服务需求也较为相似，本实施例充分利用这一特性，结合道路类型进行服务的差异化配置，从而无需进行较为复杂的计算或预测即可给出相对具有针对性的服务公告下发方案。

在一种可能的实施方式中，根据每个路侧设备标识、道路信息以及每个路侧设备覆盖范围内的车辆信息，生成每个路侧设备覆盖范围内至少一个车辆的待下发服务信息，包括：

根据每个路侧设备所处的道路信息确定服务场景类型；

根据所述服务场景类型，结合预设的服务场景类型和服务信息的对应关系，生成每个路侧设备覆盖范围内至少一个车辆的待下发服务信息。

本实施例中可以根据每个路侧设备所处的道路信息进行服务派发，相较而言，本实施例并未对车载终端是否已购买服务信息进行甄别，减小了服务下发的确定时间，可以在时间较为紧张的情况下使用。

在一种可能的实施方式中，所述道路信息包括道路类型，所述服务信息包括道路感知服务、信号灯服务、道路标识牌信息提示服务等。本实施例中道路信息包括道路类型，不同道路类型的场景大多不同，并且相同道路类型的场景大多类似，例如对于拥堵而言，在岔路口处、换道(例如上下高速的道路)上的拥堵最为严重，而直线道路往往不会产生拥堵，因此不同道路类型对应的服务、以及车载终端处于该道路段的时长均不相同，且具有较大差异，配合道路类型可以进行批量化服务下发，即相同的道路类型可以批量下发相同的服务，不同的道路类型可以进行差异化服务下发。

在一种可能的实施方式中，所述道路信息包括：道路环境和道路事件，相对应地，所述方法还包括：

根据所述道路环境和所述道路事件确定当前服务下发时间点；其中，在到达所述当前服务下发时间点之后，执行所述将每个待下发信息发送至对应的路侧设备。

本实施例中道路信息包括道路环境，例如车道拥堵状况、车道宽度、车道并线情况等，道路事件可以包括道路上发生的所有事件，例如车祸、设备故障、行车违规、天气突发状况等，本实施例结合道路环境和道路事件，可以确定出当前服务是否推迟下发或者提前下发，从而使得服务公告下发的时间点更为合适，提高了用户的使用体验，甚至可以做到无感支付，例如当前方出现车祸时，此时结合车祸在车辆快要到达车祸点时，可以播放车祸信息+行车指导服务，用户看到现场场景后为了预防后续开车风险，基于安全考虑则会优先购买，从而提高了用户体验。

在一种可能的实施方式中，所述道路事件包括设备故障，所述道路环境包括车辆拥堵状况，所述根据所述道路环境和所述道路事件确定当前服务下发时间点，包括：

根据故障设备的类型、故障类型、故障设备所处位置以及对应的维修方式，生成设备维修成功的工作时长；

根据所述工作时长确定当前服务下发时间点。

本实施例中，考虑到设备故障和拥堵情况，从而可以根据设备故障类型、故障设备所处位置等预测出设备维修时长，从而可以延迟下发，若当前某批设备现场维修阶段，不适用于服务下发，预测修复时间后，可在当前时间进行预设下发，等到维修完成再进行下发操作，提高下发效率。

在一种可能的实施方式中，所述道路事件包括设备故障，所述道路环境包括车辆拥堵状况，所述根据所述道路环境和所述道路事件确定当前服务下发时间点，包括：

根据故障设备的类型、故障类型、故障设备所处位置、对应的维修方式以及车辆拥堵状况，生成设备维修成功的工作时长；

根据所述工作时长确定当前服务下发时间点。

本实施例中进一步结合道路的拥堵状况判断设备维修时长，考虑了维修人员到场的时间，从而使得维修时长的预测更加准确。

在一种可能的实施方式中，所述根据故障设备的类型、故障类型、故障设备所处位置、对应的维修方式以及车辆拥堵状况，生成设备维修成功的工作时长，包括：

将所述故障设备的类型、故障类型、故障设备所处位置、对应的维修方式以及车辆拥堵状况输入至预设的神经网络模型，所述神经网络模型输出所述工作时长；其中所述神经网络模型是利用历史设备故障情况下，将故障情况的历史数据中的故障设备的类型、故障类型、故障设备所处位置、对应的维修方式以及车辆拥堵状况作为训练集训练得到。

本实施例中，通过神经网络模型预测工作时长，将所述故障设备的类型、故障类型、故障设备所处位置、对应的维修方式以及车辆拥堵状况作为模型的输入因子，可以准确预测出工作时长，同时进一步提高预测准确度，随着模型不断收敛，准确性越来越高，从而可以适应不同时间段的变化，保持预测准确性。

本申请第二方面实施例提供一种车联网服务信息下发方法，由路侧设备执行，包括：

获取云端服务器发送的待下发服务信息，其中所述待下发服务信息是所述云端服务器根据车联网状态信息生成，所述车联网状态信息包括：每个路侧设备标识以及每个路侧设备覆盖范围内的车辆信息；

同时，路侧设备可以根据自身的场景需求以及资源配置向云端服务器注册相关的服务；

将所述待下发服务信息发送至覆盖范围内的至少一个车载终端，以使车载终端

本申请第三方面实施例提供一种云端服务器，其特征在于，包括至少一个处理器，所述至少一个处理器用于与存储器耦合，读取并执行所述存储器中的指令，以实现上所述的方法。

本申请第四方面实施例提供一种路侧设备，包括至少一个处理器，所述至少一个处理器用于与存储器耦合，读取并执行所述存储器中的指令，以实现如上所述的方法。

本申请第五方面实施例提供一种车联网系统，所述系统包括：云端服务器和路侧设备；

所述云端服务器执行：根据车联网状态信息生成每个路侧设备覆盖范围内至少一个车辆的待下发服务信息；所述车联网状态信息包括：每个路侧设备标识以及每个路侧设备覆盖范围内的车辆信息；将每个待下发服务信息发送至对应的路侧设备，以使各路侧设备将接收的每个待下发服务信息发送至对应车辆；接收各路侧设备发送的服务支付请求，执行服务支付操作，以使车载终端兑现所述待下发服务中的服务内容；

所述路侧设备执行：获取云端服务器发送的待下发服务信息，其中所述待下发服务信息是所述云端服务器根据车联网状态信息生成，所述车联网状态信息包括：每个路侧设备标识以及每个路侧设备覆盖范围内的车辆信息；将所述待下发服务信息发送至覆盖范围内的至少一个车载终端，以使车载终端兑现所述待下发服务中的服务内容。

本申请第六方面实施例提供了一种芯片系统，该芯片系统包括处理器，用于支持云端服务器、路侧设备、车载终端实现上述方面中所涉及的功能，例如，发送或处理上述方法中所涉及的数据和/或信息。在一种可能的设计中，所述芯片系统还包括存储器，所述存储器，用于保存云端服务器、路侧设备、车载终端必要的程序指令和数据。该芯片系统，可以由芯片构成，也可以包括芯片和其他分立器件。

本申请的有益效果如下：

本申请提供的车联网服务信息下发方法和服务器、路侧设备以及系统，通过根据车联网状态信息确定出对应车辆的待下发服务信息，例如服务公告，之后将服务信息发送给路侧设备，路侧设备通过广播或者定点传输给覆盖范围内的车载终端，车载终端因此即接收到服务公告，之后根据自身需要对服务公告中的服务进行支付，从而本申请结合了数字货币和V2X共享消息两者配合，形成了车辆可以在每个服务场景下选择购买服务，即可当即享受到服务效果，提升了驾驶员的道路行驶体验。

附图说明

图1为一种车联网系统的系统架构图；

图2为本申请实施例提供的车联网服务信息下发的流程示意图；

图3为本申请实施例提供的图1中步骤301的具体流程示意图之一；

图4为本申请实施例提供的图1中步骤301的具体流程示意图之二；

图5为本申请实施例提供的一种装置的组成结构示意图。

具体实施方式

本申请实施例提供了车联网服务信息下发方法和服务器、路侧设备以及系统，用于降低车辆的通信时延。

下面结合附图，对本申请的实施例进行描述。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的术语在适当情况下可以互换，这仅仅是描述本申请的实施例中对相同属性的对象在描述时所采用的区分方式。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，以便包含一系列单元的过程、方法、系统、产品或设备不必限于那些单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它单元。

图1所示，为一种车联网系统的系统架构图，该车联网系统可以包括：云端服务器101、路侧设备102和车载终端103。

其中，云端服务器101可以是对车载终端进行管理的车联网平台或者车联网控制端。云端服务器的具体部署形态本申请不做限定，具体可以是云端部署，还可以是独立的计算机设备等。在不同的应用场景下，云端服务器101具有多种实现方式。

路侧设备102(road side unit，RSU)安装在路侧，为车辆提供通信服务，例如路侧设备可以使用PC5通信方式。本申请实施例中云端服务器和车载终端之间的通信通过路侧设备来完成。路侧设备提供通信服务使用的空口资源可以由云端服务器确定，或者由该路侧设备102与周边单元进行协商确定，例如周边单元可以是处于路侧设备102周围的路侧设备和车载终端。

本申请实施例中所述车载终端103的类型不限，可以是集成在车辆中的车载盒子(telematics BOX，T-Box)，或域控制器(domian controller，DC)，或多域控制器(multi-domian controller，MDC)，或车载单元(on board unit，OBU)等。

接下来对本申请实施例提供的车联网服务信息下发方法进行说明，请参阅图2所5示，为本申请实施例提供的云端服务器、路侧设备和车载终端之间的一种交互流程示

意图，本申请实施例提供的车联网服务信息下发方法，主要包括如下步骤：

301、云端服务器通过路侧设备获取车联网状态信息。

在本申请的一些实施例中，车联网状态信息包括：每个路侧设备标识以及每个路侧设备覆盖范围内的车辆信息。

0具体而言，可以是路侧设备将自身的设备ID发送给云端服务器，之后云端服务器

根据该设备ID确定设备在云端服务器注册的服务。

同理，每个路侧设备覆盖范围内的车辆信息可以通过路侧设备的短距离无线接收器接收到车辆发出的无线信号中携带的车辆信息确定，之后路侧设备将接收到的车辆

信息发送给云端服务器，云端服务器接收车辆信息以及对应的车辆信息的发送接口5(对应路侧设备)编号确定出每个路侧设备覆盖范围内的车辆。

311、将每个待下发服务信息发送至对应的路侧设备，以使各路侧设备将接收的每个待下发服务信息发送至对应车辆。

在本申请实施例中，云端服务器和车载终端之间使用路侧设备进行通信，首先结

合前述步骤中获取到每个车辆信息，之后云端服务器根据车辆信息对应的账户，检测0账户状态，判断账户开通了哪些服务，以及账户的开通服务偏好，结合用户的开通服

务历史数据，分析出用户的需求点，之后在获知车辆当前所处位置和车联网的其他状态信息，例如当前车辆所处位置发生的事件等，分析出该车辆当前是否存在需求点，若存在，通过该需求点进行服务推荐，确定出可以推荐的服务，之后将服务信息下发

到对应的路侧设备，路侧设备将该推荐服务进行定点传输，从而车载终端接收到的服5务信息均为需要的服务，用户当前恰好遇到了服务的需求场景，之后会结合推荐服务

选择性购买。

312、接收各路侧设备发送的服务支付请求，执行服务支付操作，以使车载终端兑现所述待下发服务中的服务内容，其中所述服务支付请求是车载终端请求购置所述待下发服务信息中的服务内容而生成，并由对应的路侧设备接收得到。

0在本申请实施例中，云端服务器从路侧设备接收到服务支付请求之后，响应于服

务支付请求而执行支付确认操作，首先通过查询车辆账户的银行账户信息或第三方支付账户信息，之后调用支付操作，形成支付链接，并发送给路侧设备。

路侧设备在接收到支付链接之后，通过定点传输发送至对应的车辆，从而车辆点击支付链接之后，在银行或者第三方支付插件下输入密码或者指纹，完成支付操作。

在一种可能的实施方式中，所述根据每个路侧设备标识以及每个路侧设备覆盖范围内的车辆信息，生成每个路侧设备覆盖范围内至少一个车辆的待下发服务信息，如图3所示，包括：

S111：根据每个路侧设备标识查找预设的路侧设备标识与服务信息的对应关系，

得到每个路侧设备对应的服务信息；

S112：获取每个路侧设备覆盖范围内所有车辆的账户信息，并根据所述账户信息查找每个车辆的已购置服务信息；

S113：根据每个路侧设备对应的服务信息以及对应的覆盖范围内每个车辆的已购置服务信息，确定每个车辆的所述待下发服务信息。

本实施例中示出了具体的待下发服务信息的生成过程，从而可以根据路侧设备的标识进行批量的服务下发，路侧设备根据自身的场景需求以及资源配置在云端服务器注册对应的服务，云端服务器可以根据对应的标识进行服务的下发，并且配合路侧设备对每个车辆已购置服务进行信息提取，从而避免了重复推送导致用户体验感下降的问题。

在一种可能的实施方式中，所述车联网状态信息还包括：道路信息，相对应地，所述根据车联网状态信息生成每个路侧设备覆盖范围内至少一个车辆的待下发服务信息，包括：

根据每个路侧设备标识、道路信息以及每个路侧设备覆盖范围内的车辆信息，生成每个路侧设备覆盖范围内至少一个车辆的待下发服务信息。

本实施例进一步结合道路信息进行待下发服务信息的推送，从而可以考虑道路突发状况，例如道路出现车祸、堵车或者公共设施损坏等，均可以精准地给出服务推荐，进一步提高用户体验。

在一种可能的实施方式中，根据每个路侧设备标识、道路信息以及每个路侧设备覆盖范围内的车辆信息，生成每个路侧设备覆盖范围内至少一个车辆的待下发服务信息，包括：

S121：根据每个路侧设备所处的道路信息确定服务场景类型；

S122：根据所述服务场景类型，结合预设的服务场景类型和服务信息的对应关系，确定每个路侧设备对应的服务信息；

S123：获取每个路侧设备覆盖范围内所有车辆的账户信息，并根据所述账户信息查找每个车辆的已购置服务信息；

S124：根据每个路侧设备对应的服务信息以及对应的覆盖范围内每个车辆的已购置服务信息，确定每个车辆的所述待下发服务信息。

举例而言，路侧设备所述的道路信息为十字路口，通过查找对应关系表可以得到十字路口需要哪些服务场景，例如道路感知、信号灯、道路标牌信息提示等。之后查找车辆账户已经购买了哪些服务，例如A车辆购买了道路感知服务、信号灯服务，但是尚未购买道路标牌信息提示服务，此时结合用户的已购置服务信息可以得出用户偏向使用道路安全方面的功能，云端服务器即根据已购置的服务信息确定推送道路标牌信息提示服务，之后将该服务信息下发到覆盖该车辆的路侧设备，由路侧设备将道路标牌信息提示服务的服务介绍和服务价格推送给车辆A，车辆A的用户看到之后确认支付，则完成了服务下发支付操作。

本实施例中每种道路可能存在近似的道路状况，因此结合道路类型可以大致得到类似的道路状况，而类似的道路状况大多数的服务需求也较为相似，本实施例充分利用这一特性，结合道路类型进行服务的差异化配置，从而无需进行较为复杂的计算或预测即可给出相对具有针对性的服务公告下发方案。

在一种可能的实施方式中，根据每个路侧设备标识、道路信息以及每个路侧设备覆盖范围内的车辆信息，生成每个路侧设备覆盖范围内至少一个车辆的待下发服务信息，包括：

S131：根据每个路侧设备所处的道路信息确定服务场景类型；

S132：根据所述服务场景类型，结合预设的服务场景类型和服务信息的对应关系，生成每个路侧设备覆盖范围内至少一个车辆的待下发服务信息。

本实施例中可以根据每个路侧设备所处的道路信息进行服务派发，相较而言，本实施例并未对车载终端是否已购买服务信息进行甄别，减小了服务下发的确定时间，可以在时间较为紧张的情况下使用。

举例而言，路侧设备所述的道路信息为下高速的岔路口，通过查找对应关系表可以得到下高速的岔路口需要哪些服务场景，例如道路感知、信号灯、道路标牌信息提示等。但是由于车辆处于高速上，车速较快，给用户的反应时间较少，从而可以跳过查找车辆账户已经购买了哪些服务的步骤，云端服务器直接将所有相关的服务信息下发到覆盖该车辆的路侧设备，由路侧设备将道路标牌信息提示服务的服务介绍和服务价格推送给车辆A，车辆A的用户看到之后选择性地确认支付，则完成了服务下发支付操作。

在一种可能的实施方式中，所述道路信息包括道路类型，所述服务信息包括道路感知服务、信号灯服务、道路标识牌信息提示服务。本实施例中道路信息包括道路类型，不同道路类型的场景大多不同，并且相同道路类型的场景大多类似，例如对于拥堵而言，在岔路口处、换道(例如上下高速的道路)上的拥堵最为严重，而直线道路往往不会产生拥堵，因此不同道路类型对应的服务、以及车载终端处于该道路段的时

长均不相同，且具有较大差异，配合道路类型可以进行批量化服务下发，，即相同的5道路类型可以批量下发相同的服务，不同的道路类型可以进行差异化服务下发。

在一种可能的实施方式中，所述道路信息包括：道路环境和道路事件，相对应地，所述方法还包括：

根据所述道路环境和所述道路事件确定当前服务下发时间点；其中，在到达所述当前服务下发时间点之后，执行所述将每个待下发信息发送至对应的路侧设备。

0本实施例中道路信息包括道路环境，例如车道拥堵状况、车道宽度、车道并线情

况等，道路事件可以包括道路上发生的所有事件，例如车祸、设备故障、行车违规、

天气突发状况等，本实施例结合道路环境和道路事件，可以确定出当前服务是否推迟下发或者提前下发，从而使得服务公告下发的时间点更为合适，提高了用户的使用体

验，甚至可以做到无感支付，例如当前方出现车祸时，此时结合车祸在车辆快要到达5车祸点时，可以播放车祸信息+行车指导服务，用户看到现场场景后为了预防后续开车

风险，基于安全考虑则会优先购买，从而提高了用户体验。

在一种可能的实施方式中，所述道路事件包括设备故障，所述道路环境包括车辆拥堵状况，所述根据所述道路环境和所述道路事件确定当前服务下发时间点，包括：

根据故障设备的类型、故障类型、故障设备所处位置以及对应的维修方式，生成0设备维修成功的工作时长；

根据所述工作时长确定当前服务下发时间点。

本实施例中，考虑到设备故障和拥堵情况，从而可以根据设备故障类型、故障设备所处位置等预测出设备维修时长，从而可以延迟下发，若当前某批设备现场维修阶

段，不适用于服务下发，预测修复时间后，可在当前时间进行预设下发，等到维修完5成再进行下发操作，提高下发效率。

在一种可能的实施方式中，所述道路事件包括设备故障，所述道路环境包括车辆拥堵状况，所述根据所述道路环境和所述道路事件确定当前服务下发时间点，包括：

根据故障设备的类型、故障类型、故障设备所处位置、对应的维修方式以及车辆

拥堵状况，生成设备维修成功的工作时长；

0根据所述工作时长确定当前服务下发时间点。

本实施例中进一步结合道路的拥堵状况判断设备维修时长，考虑了维修人员到场的时间，从而使得维修时长的预测更加准确。

在一种可能的实施方式中，所述根据故障设备的类型、故障类型、故障设备所处位置、对应的维修方式以及车辆拥堵状况，生成设备维修成功的工作时长，包括：

将所述故障设备的类型、故障类型、故障设备所处位置、对应的维修方式以及车辆拥堵状况输入至预设的神经网络模型，所述神经网络模型输出所述工作时长；其中所述神经网络模型是利用历史设备故障情况下，将故障情况的历史数据中的故障设备的类型、故障类型、故障设备所处位置、对应的维修方式以及车辆拥堵状况作为训练集训练得到。

本实施例中，通过神经网络模型预测工作时长，将所述故障设备的类型、故障类型、故障设备所处位置、对应的维修方式以及车辆拥堵状况作为模型的输入因子，可以准确预测出工作时长，同时进一步提高预测准确度，随着模型不断收敛，准确性越来越高，从而可以适应不同时间段的变化，保持预测准确性。

本申请的具体场景中，在数字人民币支付+V2X服务场景下，本方法涵盖云端子系统、RSU路侧子系统两个子系统，两个子系统通过tcp、IP协议族协议来连接(如MQTT协议等)，连接认证及数据传输安全，通过TLS双向认证等安全认证加密传输，收费公告信息由云端子系统根据需求进行配置，其中涵盖：收费方信息(收费方公司名称、与用户收费须知协议等)+多个收费单元；收费单元里包含：单元名称(或唯一ID号)、收费单价、收费时段信息等；数据格式不做限定，由云端通过配置好的收费信息下发至路侧收费单元RSU设备，收费单元可以将收费信息存储在本地，同时将收费信息解析后组成收费广播消息进行广播通知，在该路侧RSU收费单元覆盖范围内，凡经过的车辆只要是装载有车载OBU单元都将收到该收费公告，司机或驾驶人员可选择进行购买，购买完成后，已付费车辆可根据付款凭证信息对路侧收费单元广播的V2X道路服务信息进行交互，并享受该服务的道路感知结果、道路事件、标牌提示等。

为便于更好的理解和实施本申请实施例的上述方案，下面举例相应的应用场景来进行具体说明。

在一高速智能变道提示的场景中，云端服务器首先实时获取路侧设备感知的所有车辆信息，以及路侧设备检测的车辆所处车道信息，配合其他路侧设备检测的道路拥堵信息、道路障碍等，当前方200米的第一车道发生交通事故时，路侧设备第一时间获知到该事故信息以及事故所处车道为第一车道，则云端服务器调用200米范围内的路侧设备的感知数据，确定在距离交通事故点位置200米范围内的所有车辆。

之后，确定所有车辆所处车道是否为第一车道，若检测出例如20辆车处于第一车道，调取该20辆车的账户信息，查找每个车辆已订购的服务，若车辆没有订购该服务，则向处于第一车道内的车载终端推送是否订购变道提醒服务。

云端服务器推送变道提醒服务至该200米范围内的路侧设备，由路侧设备向处于第一车道内且未订购服务的车辆推送变道提醒服务，以及对应的服务简介、服务价格等。

车载终端若订购该服务，则云端服务器通过路侧设备发送支付链接，从而完成支付操作。

本申请提供的车联网服务信息下发方法，通过根据车联网状态信息确定出对应车辆的待下发服务信息，例如服务公告，之后将服务信息发送给路侧设备，路侧设备通过广播或者定点传输给覆盖范围内的车载终端，车载终端因此即接收到服务公告，之后根据自身需要对服务公告中的服务进行支付，从而本申请结合了数字货币和V2X共享消息两者配合，形成了车辆可以在每个服务场景下选择购买服务，即可当即享受到服务效果，提升了驾驶员的道路行驶体验。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

为便于更好的实施本申请实施例的上述方案，下面还提供用于实施上述方案的相关装置。

例如，如上实施例中的集成在车辆上的车载终端，云端服务器，路侧设备均可以由如图5所示的装置来实现。

装置1000包括至少一个处理器1001，通信总线1002，存储器1003以及至少一个通信接口1004。装置1000可以是一个通用计算机或服务器或者是一个专用计算机或服务器。

处理器1001可以是一个通用中央处理器(central processing unit，CPU)，微处理器，特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制本发明方案程序执行的集成电路。

通信总线1002可包括一通路，在上述组件之间传送信息。

通信接口1004，可以是任何收发器或IP端口或总线接口等，用于与内部或外部设备或装置或通信网络通信，如以太网，无线接入网(radio access network，RAN)，无线局域网(wireless local area networks，WLAN)等。如车载终端为集成在车辆内部的功能单元时，车载终端的通信接口1004可能包括与车辆外部网络进行通信的收发器，还包括与车辆其它内部单元通信的总线接口，如控制器局域网络(Controller AreaNetwork,CAN)总线接口等。

存储器1003可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electrically erasable programmable read-only memory，EEPROM)、只读光盘(compactdisc read-only memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过总线与处理器相连接。存储器也可以和处理器集成在一起。

其中，存储器1003用于存储执行本发明方案的应用程序代码，并由处理器1001来控制执行。处理器1001用于执行存储器1003中存储的应用程序代码，从而实现本专利方法中云端服务器的功能。

在具体实现中，作为一种实施例，处理器1001可以包括一个或多个CPU，例如图5中的CPU0和CPU1。

在具体实现中，作为一种实施例，装置1000可以包括多个处理器，例如图5中的处理器1001和处理器1008。这些处理器中的每一个可以是一个单核(single-CPU)处理器，也可以是一个多核(multi-CPU)处理器。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。

在具体实现中，作为一种实施例，装置1000还可以包括输出设备1005和输入设备1006。输出设备1005和处理器1001通信，可以以多种方式来显示信息。例如，输出设备1005可以是液晶显示器(liquid crystal display，LCD),发光二级管(light emitting diode，LED)显示设备，阴极射线管(cathode ray tube，CRT)显示设备，或投影仪(projector)等。输入设备1006和处理器1001通信，可以以多种方式接受用户的输入。例如，输入设备1006可以是鼠标、键盘、触摸屏设备或传感设备等。

当图5所示的装置为芯片时，通信接口1004的功能/实现过程还可以通过管脚或电路等来实现，所述存储器为所述芯片内的存储单元，如寄存器、缓存等，所述存储单元还可以是位于所述芯片外部的存储单元。

需要说明的是，上述装置各模块/单元之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其带来的技术效果与本申请方法实施例相同，具体内容可参见本申请前述所示的方法实施例中的叙述，此处不再赘述。

本申请实施例还提供一种计算机存储介质，其中，该计算机存储介质存储有程序，该程序执行包括上述方法实施例中记载的部分或全部步骤。

另外需说明的是，以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本申请提供的装置实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专用CPU、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多样的，例如模拟电路、数字电路或专用电路等。但是，对本申请而言更多情况下软件程序实现是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘、U盘、移动硬盘、ROM、RAM、磁碟或者光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。

所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(Solid State Disk，SSD))等。