车机设备、后装ETC设备及其通信方法、系统与流程

车机设备、后装etc设备及其通信方法、系统
技术领域
1.本发明涉及etc通信领域，尤其涉及一种车机设备、后装etc设备及其通 信方法、系统。


背景技术：

2.etc(electronic toll collection，电子不停车收费系统)的主要业务场景是 面向高速公路或桥梁自动收费。通过安装在车辆挡风玻璃上的车载电子标签 与在收费站etc车道上的微波天线之间进行的专用短程通讯，利用计算机联 网技术与银行进行后台结算处理，从而达到车辆通过高速公路或桥梁收费站 无需停车而能交纳高速公路或桥梁费用的目的。
3.车辆上的etc设备分为前装式和后装式，其中，前装式是车辆出厂时就已 装好etc设备，而后装式则是在购车后用户自行办理安装，目前市面上的 etc设备基本上是后装式的，而且，现有的后装式etc设备是作为一独立的 设备固定在车辆上的，并无与车辆的车机设备有任何的信息交互，这也就无法 实现一些附加功能，使得用户体验不高。


技术实现要素：

4.本发明要解决的技术问题在于，现有技术存在的无法实现车机设备与后 装etc设备之间的信息交互的缺陷。
5.本发明解决其技术问题所采用的技术方案是：构造一种车机设备与后装 etc设备的通信方法，应用于车机设备，包括：
6.监听用户的操作信号；
7.根据所述操作信号生成请求信息，并通过内置的etc模组向后装etc设备 发送所述请求信息；
8.通过内置的etc模组接收后装etc设备发送的返回信息，并进行相应的输 出。
9.优选地，进行相应的输出，包括：
10.对所接收的所述返回信息进行校验，并判断是否校验成功；
11.若校验成功，则输出所述返回信息；
12.若校验失败，则输出操作失败提示信息。
13.优选地，所述用户的操作信号包括：剩余电量/通行费用的查询信号；
14.根据所述操作信号生成请求信息，包括：根据所述剩余电量/通行费用的 查询信号生成电量/通行请求报文；
15.所述返回信息包括：电量/通行数据报文，其中，所述电量/通行数据报文 由所述后装etc设备在接收到电量/通行请求报文时，通过获取所述后装etc 设备的当前电量/通行信息所生成。
16.优选地，所述用户的操作信号包括：付费项目的购买信号；
17.根据所述操作信号生成请求信息，包括：根据所述付费项目的购买信号生 成预付
费请求报文；
18.所述返回信息包括：预付费应答报文，其中，所述预付费应答报文由所述 后装etc设备在接收到预付费请求报文时，获取预付费信息，并将其写入预付 费缓存数据库，且根据写入结果所生成。
19.优选地，还包括：
20.监听与所述etc模块连接的串口；
21.通过内置的etc模组接收后装etc设备发送的扣费数据报文，其中，所述 后装etc设备在处于计费状态时，从所述预付费缓存数据库中读出所述预付费 信息，并将其发送至rsu设备进行扣费操作，而且，在扣费成功时，清除所 述预付费缓存数据库中的所述预付费信息，并生成所述扣费数据报文。
22.优选地，还包括：
23.在收到所述扣费数据报文时，通过内置的etc模组向后装etc设备发送扣 费应答报文。
24.本发明还构造一种车机设备与后装etc设备的通信方法，应用于后装etc 设备，所述后装etc设备包括dsrc端口，包括：
25.监听所述dsrc端口的数据信息；
26.根据所监听到数据信息生成相应的返回信息；
27.通过所述dsrc端口将其发送至车机设备的etc模组。
28.优选地，所监听到数据信息包括来自车机设备的电量/通行请求报文；
29.根据所监听到数据信息生成相应的返回信息，包括：
30.根据所述电量/通行请求报文获取当前电量/通行信息，并根据当前电量/ 通行信息生成电量/通行数据报文。
31.优选地，所监听到信息包括来自车机设备的预付费请求报文；
32.根据所监听到数据信息生成相应的返回信息，包括：
33.根据所述预付费请求报文提取其中的预付费信息，并将其写入预付费缓存 数据库，且根据写入结果生成预付费应答报文。
34.优选地，还包括：
35.检测是否处于计费状态；
36.在处于计费状态时，从所述预付费缓存数据库中读出所述预付费信息，并 将其发送至rsu设备进行扣费操作；
37.而且，所监听到数据信息包括来自所述rsu设备的扣费成功信息；
38.根据所监听到数据信息生成相应的返回信息，包括：
39.根据所述扣费成功信息清除所述预付费缓存数据库中的所述预付费信息， 并生成扣费数据报文。
40.本发明还构造一种车机设备，包括第一处理器及存储有第一计算机程序的 第一存储器，所述第一处理器在执行所述第一计算机程序时实现以上所述的通 信方法的步骤。
41.本发明还构造一种后装etc设备，包括第二处理器及存储有第二计算机程 序的第二存储器，所述第二处理器在执行所述第二计算机程序时实现以上所述 的通信方法的步骤。
42.本发明还构造一种通信系统，包括以上所述的车机设备及以上所述的后装 etc设备。
43.本发明所提供的技术方案，车机设备通过内置的etc模组可与后装etc 设备进行无线dsrc通信，打通了车机设备与后装etc设备的软件通信链路， 在无需互联网接入的情况下实现了车机设备与后装etc设备之间的信息交互， 为实现附加功能奠定了基础，提升了车机的附加价值及用户体验。
附图说明
44.为了更清楚地说明本发明实施例，下面将对实施例描述中所需要使用的 附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实 施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可 以根据这些附图获得其他的附图。附图中：
45.图1是本发明车机设备与后装etc设备的通信系统实施例一的逻辑框图；
46.图2是本发明车机设备与后装etc设备的通信方法实施例一的流程图；
47.图3是本发明车机设备与后装etc设备的通信方法实施例二的流程图；
48.图4a是本发明车机设备与后装etc设备的通信方法实施例三的部分流程 图；
49.图4b是本发明车机设备与后装etc设备的通信方法实施例三的部分流程 图；
50.图5是本发明车机设备与后装etc设备的通信方法实施例四的流程图；
51.图6是本发明车机设备与后装etc设备的通信方法实施例五的流程图；
52.图7是本发明实施例提供的车机设备的示意性框图；
53.图8是本发明实施例提供的后装etc设备的示意性框图。
具体实施方式
54.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行 清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而 不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做 出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
55.针对目前现有技术存在的车辆的后装etc设备与车机设备无任何的信息 交互的技术问题，有必要设计出一种车机设备对后装etc设备进行读写访问的 技术方案，首先，实现该技术方案需要硬件的支撑，具体地，如图1所示，在 车机设备中内置etc模组，即，车机设备包括相连接的车机主体及etc模组， 例如，通过串口连接车机主体与etc模组，车机主体和后装etc设备之间的通 信是通过etc模组来实现转发的。
56.图2是本发明车机设备与后装etc设备的通信方法实施例一的流程图，该 通信方法应用于车机设备，车机设备例如为车辆上具有人机操作界面的中控设 备，而且，该实施例的通信方法包括：
57.步骤s11.监听用户的操作信号；
58.步骤s12.根据所述操作信号生成请求信息，并通过内置的etc模组向后装 etc设备发送所述请求信息；
59.步骤s13.通过内置的etc模组接收后装etc设备发送的返回信息，并进行 相应的
输出。
60.进一步地，在步骤s13中，进行相应的输出，具体包括：
61.对所接收的所述返回信息进行校验，并判断是否校验成功；
62.若校验成功，则输出所述返回信息；
63.若校验失败，则输出操作失败提示信息。
64.图3是本发明车机设备与后装etc设备的通信方法实施例二的流程图，该 通信方法应用于后装etc设备中，该后装etc设备包括dsrc端口，而且，该 实施例的通信方法包括：
65.步骤s21.监听所述dsrc端口的数据信息；
66.步骤s22.根据所监听到数据信息生成相应的返回信息；
67.步骤s23.通过所述dsrc端口将其发送至车机设备的etc模组。
68.在上述实施例中，应理解，车机设备的hmi是一整套汽车中控人机界面 交互软件，运行在车机主体hmi系统中的一个子系统仅针对与etc模组相连 接的串口进行读写操作。运行在etc模组内的软件程序的作用是将与车机主体 相连接的串口数据指令转发到etc模组的dsrc端口，将etc模组自身dsrc 端口数据指令转发到自身串口。运行在后装etc设备的软件程序主要负责从自 身dsrc端口读取数据指令，然后存储在设备内部的可读写存储区域内，另外 会根据车机端的请求指令回传数据或者响应信息到车机，这部分在软件层面的 操作就是将数据或者响应信息发送到自身的dsrc端口。
69.通过上述实施例的技术方案，车机设备通过内置的etc模组可与后装etc 设备进行无线dsrc通信，打通了车机设备与后装etc设备的软件通信链路， 在无需互联网接入的情况下实现了车机设备与后装etc设备之间的信息交互， 为实现附加功能奠定了基础，提升了车机的附加价值及用户体验。
70.在一个应用场景中，etc高速公路通行费用关系到车主的核心利益，如果 能将高速公路/桥梁通行信息通过车机设备屏予以显示出来，则为车主了解自 身车辆通行信息(包括收费公路通行里程、收费公路通行路线、收费公路通行 费用等)提供了一个极其便携的方式，这些收费公路通行信息可以为车主提供 出行规划、车辆通行财务预算，车辆防盗追踪作为重要的参考数据。这是本 申请所面向的第一个应用场景以及所要解决的行业需求。
71.针对该应用场景，在本发明车机设备与后装etc设备的通信方法的一个实 施例中，步骤s11中用户的操作信号包括：剩余电量/通行费用的查询信号。 步骤s12中根据所述操作信号生成请求信息包括：根据所述剩余电量/通行费 用的查询信号生成电量/通行请求报文。步骤s13中返回信息包括：电量/通行 数据报文，其中，所述电量/通行数据报文由所述后装etc设备在接收到电量/ 通行请求报文时，通过获取所述后装etc设备的当前电量/通行信息所生成。
72.相应地，步骤s21中所监听到数据信息包括来自车机设备的电量/通行请 求报文。步骤s22中根据所监听到数据信息生成相应的返回信息包括：根据所 述电量/通行请求报文获取当前电量/通行信息，并根据当前电量/通行信息生 成电量/通行数据报文。其中，通行信息可包括收费公路通行里程、收费公路 通行路线、收费公路通行费用等信息。
73.通过上述实施例的技术方案，当车主通过车机设备输入剩余电量/通行费 用的查询信号后，车机设备根据该查询信号生成相应的请求报文，然后通过 etc模组发送至后装
etc设备。后装etc设备在收到该请求报文后，读取当前 的电量/通行信息，并生成相应的数据报文，然后将其发送至车机设备的etc 模组。这样，车主便可通过车机设备了解自身车辆的通行信息，为车主提供出 行规划、车辆通行财务预算、车辆防盗追踪等重要的参考数据。
74.在另一个应用场景中，etc付费场景不断拓展，车机设备端付费业务与 etc进行衔接也是汽车智能座舱的重要业务布局。随着中国汽车行业蓬勃发 展，私人汽车保有量大规模增加，汽车厂商和汽车零部件供应商不断在汽车 网联技术，汽车多媒体技术方面发力，使得汽车联网功能越来越强大，汽车 中控端多媒体车机设备功能越来越丰富，诸如在线付费音乐、在线付费视频、 在线付费电影电视剧、在线付费小说、在线付费游戏与装备、在线汽车购物等 功能必将成为下一代汽车端多媒体增值业务的重要方向，汽车中控车机设备 屏幕将成为汽车多媒体增值娱乐业务的入口，借助车联网技术与功能丰富的 多媒体车机设备技术，汽车与汽车电子以及汽车互联网行业内的汽车厂商， 车机设备厂商，在线互联网多媒体娱乐业务运营商共同发力撬动汽车端互联 网娱乐增值业务消费并将使其成为一个重要的未来汽车端业务场景。该业务 场景能为车主丰富汽车内娱乐功能，并推动汽车和交通行业整体发展，从而 拉动内需，创造更好的国民经济发展示例。有消费场景就必须有支付机制和 支付渠道提供支撑，如果没有便携的支付接口与支付渠道，则会严重影响用 户体验，尤其是如果没有优秀的用户体验，则会大大降低用户在车内购买影 音文字和游戏类多媒体增值娱乐业务的消费动力和积极性。优秀的用户体验 意味着对于用户来说一定要做到操作简单易懂，提示简洁清晰，具体来说最 好是傻瓜式操作，且达到无感支付的程度。而对于开发者来说优秀的用户体 验即意味着必须创造并设计出一种极为便携简单的车内付费场景，无需手机 与手机端支付类应用介入。当用户确定购买意向且达成付费交易后，费用账 单会暂时缓存到etc车载端，当汽车通过任何有etc收费站的道路桥梁时，会 自动将缓存在etc车载端的费用账单通过收费站进行结算，结算成功后由公 路运营单位通过一定的结算机制将该笔费用转给第三方互联网多媒体娱乐增 值业务运营商。这是本技术所面向的第二个应用场景以及所要解决的行业需 求。
75.针对该应用场景，在本发明车机设备与后装etc设备的通信方法的一个实 施例中，步骤s11中的用户的操作信号包括：付费项目(例如，在线付费音乐、 在线付费视频、在线付费电影电视剧、在线付费小说、在线付费游戏与装备、 在线汽车购物)的购买信号。步骤s12中根据所述操作信号生成请求信息，包 括：根据所述付费项目的购买信号生成预付费请求报文。步骤s13中的返回信 息包括：预付费应答报文，其中，所述预付费应答报文由所述后装etc设备在 接收到预付费请求报文时，获取预付费信息，并将其写入预付费缓存数据库， 且根据写入结果所生成。
76.相应地，步骤s21中所监听到信息包括来自车机设备的预付费请求报文。 步骤s22中根据所监听到数据信息生成相应的返回信息，包括：根据所述预付 费请求报文提取其中的预付费信息，并将其写入预付费缓存数据库，且根据写 入结果生成预付费应答报文。
77.进一步地，后装etc设备还进行以下步骤：检测是否处于计费状态；在处 于计费状态时，从所述预付费缓存数据库中读出所述预付费信息，并将其发送 至rsu设备进行扣费操作。而且，所监听到数据信息包括来自所述rsu设备 的扣费成功信息。步骤s22中根据所监听到数据信息生成相应的返回信息，包 括：根据所述扣费成功信息清除所述预付费缓存数据库中的所述预付费信息， 并生成扣费数据报文。另外，在收到所述扣费数据报文时，还
通过内置的etc 模组向后装etc设备发送扣费应答报文。
78.相应地，车机设备还进行以下步骤：监听与所述etc模块连接的串口；通 过内置的etc模组接收后装etc设备发送的扣费数据报文，其中，所述后装 etc设备在处于计费状态时，从所述预付费缓存数据库中读出所述预付费信 息，并将其发送至rsu设备进行扣费操作，而且，在扣费成功时，清除所述 预付费缓存数据库中的所述预付费信息，并生成所述扣费数据报文。
79.上述实施例的技术方案为汽车用户和车内增值娱乐业务应用运营商提供 支付渠道和支付机制层面的软件支撑，且极大的方便了车内场景支付模式和支 付流程，做到了傻瓜式的车内无感支付环境。只有当有了支付流程软件层面的 技术支撑且做到极佳的用户体验，才能为汽车用户提供丰富的汽车内娱乐功 能，用户愿意购买车机付费业务，从而推动汽车和交通行业整体发展，拉动国 家内需，创造更好的国民经济发展示例。
80.在一个具体实施例中，鉴于以上两种应用场景，设计出一种汽车车机对后 装车载etc设备进行读写访问的软件技术方案，首先该技术方案要满足如下几 个条件：
81.1.车机设备内置etc模组，且该etc模组与车机主体使用uart串口进行 通信；
82.2.车机可以隔空读取后装etc设备中的通行数据和车辆信息；
83.3.车机可以向后装etc设备隔空发送控制指令、应答消息和普通数据；
84.4.后装etc设备可以隔空向车机发送普通数据和应答消息；
85.5.后装etc设备可以隔空读取车机数据；
86.6.车机向车辆后装etc设备读写数据与信令不能被相邻车辆干扰。
87.针对上面六个条件，要满足第1个条件，则需要使用一个与etc无线通 信制式相同的模组内置到车机设备内部，才能实现车机设备与后装etc设备的 无线通信交互。要满足第2个条件，则需要先在车机主体端创建一个串口接收 线程，然后在etc模组中创建一个接收dsrc数据与信令并转发到串口的透传 线程。要满足第3个条件，则需要先在车机主体端创建一个串口发送线程，然 后在etc模组中创建一个接收串口数据与信令并转发到dsrc的透传线程。要 满足第4个条件，则需要在后装etc设备中创建一个dsrc发送线程，即，数 据和信令将被发送到后装etc设备中的dsrc端口。要满足第5个条件，则需 要在后装etc设备中创建一个dsrc接收线程，即，数据和信令将从后装etc 设备中的dsrc端口读取到其运行内存或者固态内存中。要满足第6个条件， 需要在车机主体端软件、etc模组端软件、后装etc车载设备端软件中都进行 身份鉴别，确保是同一辆车上的车机设备的etc模组、后装etc设备在执行当 前业务流程。以上满足条件所需要创建的软件线程可以是多个，也可以是同时 满足多个条件的一个线程。
88.另外，车机主体端、etc模组端、后装etc设备端之间的软件交互都是通 过数据指令报文来进行的，车机设备端有独立定义的数据指令报文格式，后装 etc设备端有独立定义的数据信令报文格式，etc模组对于两端传输的数据指 令报文都做转发透传。
89.首先，关于车机主体端发送的数据信令报文格式，如表1-1所示，在该表 中，第一行表示的是每一个子段对应的字节长度及其标识代码，其中，当前业 务标示代码代表报文的接收方当前软件业务，即，车机设备与后装etc设备之 间的通信业务；车辆唯一识别号码(vin)代表报文的接收方当前流程只处理 当前车辆的车机设备端、etc模组端、后装etc设备报文信息，来自其他车辆 车机设备的数据指令报文业务不予受理；车机设备端标识代码
是标识当前报 文信息的源设备端口为车机设备端。
[0090][0091]
表1-1
[0092]
消息内容段又分为三种消息内容格式：读请求标识代码、写请求标识代码、 应答消息类型标识代码。
[0093]
关于车机主体端发送的读请求类型的消息内容，其格式如表1-2所示，读 请求有两种更细分的请求类型：读通行费用；读剩余电池电量，其类型代码分 别是0x98、0x67。
[0094][0095]
表1-2 关于车机主体端发送的写请求类型的消息内容，其格式如表1-3所示。
[0096][0097]
表1-3
[0098]
关于表1-3中的“写入数据内容”，其主要是预付费的交易信息，例如， 车主或者车内用户点击车机设备上付费小说并确认付费购买，则写入的数据内 容如表1-4所示，具体包含：消费交易日期时间、付费小说app应用名称、付 费小说app运营商名称、付费小说app运营商银行卡账号、购买当前付费小 说的消费金额。这些预付费的交易信息以报文的形式会最终发送到后装etc设 备端，后装etc设备端会将这些预付费信息缓存起来，等待合适的时机执行实 际的扣费操作。
[0099][0100]
表1-4
[0101]
关于车机主体端发送的应答类型的消息内容，首先说明的是，每一个写请 求数据指令报文在发送之后都要等待接收方的一个应答消息，因此，车机主体 端在收到后装etc设备发送过来的数据信令报文后，需要对等的发送应答报文 给到后装etc设备。应答类型的消息内容格式比较简单，标识代码占一个字节 长度，实际应答消息占一个字节长度，如果当前流程节点操作成功，则发回成 功(successful)的应答响应，用16进制0x32表示，如果当前流程节点操作失 败，则发回失败(failed)的应答响应，用16进制0x01表示。
[0102]
在一个具体实施例中，结合图4a，车机主体的hmi主程序会监听用户在 车机触摸显示屏上的各种操作，并根据对应的操作信号生成不同的请求。如果 是想查询高速公路通行信息或者obu(后装etc设备)剩余电量信息，则生成 读obu请求报文；如果是确认购买车机app内的某个付费项目，则生成对应 的预付费写请求报文。无论是读obu请求的数据指令报文还是预付费写请求 数据指令报文，都遵循表1-1所规定的报文格式。
[0103]
读请求流程与写请求流程这两个软件流程在同一时刻只能有一个流程在 执行，因为两个流程对于用户在车机设备端的操作来说只可能存在一种操作， 所以整个软件流程都是一个串行化执行的单线程，只是针对不同的车机设备端 操作走向不同的软件流程。
[0104]
在读请求流程中，不会收到后装etc设备发回的应答(ack)报文，只会 收到实际要请求的数据报文，例如，若请求获取obu剩余电量，则收到的是 封装后的obu剩余电量数据报文，收到后需要做报文校验，主要是提取当前 业务标识代码，对比车辆唯一识别标识(vin码)，判断数据信令报文源端口 是否来自本车辆上的后装etc设备。读请求流程完成后会返回到hmi主程序， 继续监听用户对车机触摸显示屏的操作。
[0105]
在写请求流程中，经过生成报文、发送报文到串口、接收应答ack、校验 应答ack、返回到hmi主程序，继续监听用户对车机触摸显示屏等9个软件 节点的操作。其中，应答ack是特定格式的报文，遵循后装etc设备的obu 应答报文格式。
[0106]
进一步地，车机主体端还需要接收读取后装etc设备发送过来的数据报 文，而且，只会在以下一种情况下收到后装车载etc设备发送过来的数据报文： 后装etc设备内有缓存的预付费信息且车辆正在通过或已经通过高速公路etc 收费站出口。车机设备端收到的数据报文是通过内置的etc模组所转发的数据 报文，所以车机主体端需要监听与etc模组连接的串口，此时，hmi主程序子 线程阻塞监听串口数据。当后装etc设备发送过来数据报文后，结合图4b， 车机主体端会在自身串口(与etc模组相连接的串口)端侦测到有串口数据写 入并及时读取这些数据，读取来的数据即按照实际扣费数据报文格式予以解 析，如表2-1所示。而且，对应的消息内容的字段格式如表2-3所示。
[0107]
报文校验主要是检测扣费数据报文(表2-1所示)中的当前软件业务标识 代码、车辆唯一识别号码、后装车载etc设备端标识代码，如果这三个信息元 素不满足报文格式要求，则直接抛弃，然后生成并发送表征失败的应答报文， 然后回到子线程循环段入口重新监听车机主体的串口。如果报文校验成功，则 将扣费成功的实际扣费信息写入车机本地数据库，写入车机本地数据库的目的 是在于给用户查询车机app付费业务的实际扣费记录。如果写入数据库成功， 则生成表征成功的应答报文，如果写入数据库失败，则生成表征失败的应答报 文，并将应答报文发回后装etc设备端。
[0108]
在etc模组端，其在执行串口/dsrc数据指令转发(透传)程序时，结合 图5，当主程序开始后，首先创建硬件端口监听集合，并将etc模组串口添加 到监听集合，以及将etc模组dsrc端口添加到监听集合中，然后创建循环体。 etc模组端程序是一个无限循环体，在循环体内监听串口和dsrc端口的事件。 如果事件来自串口，则将车机主体通过串口发过来的数据指令不做任何拆包解 读的操作，直接转发到dsrc端口；如果事件来自dsrc端口，则将后装etc 设备通过dsrc端口发过来的数据指令不做任何拆包解读的操作，直接转发到 串口。转发完成后回到循环体入口，继续监听串口和dsrc端口的事件。
[0109]
下面说明后装etc设备端发送的数据信令报文格式，如表2-1所示，表中 第一行表
示的是每一个子段对应的字节长度，第二行表示的报文中的各个子段 内容，其中，当前软件业务标志代码代表报文的接收方所关联的业务，即，车 机设备与后装etc之间的数据信令通信业务；车辆唯一识别号码(vin)是报 文的接收方当前软件流程只处理当前车辆的车机主体端、etc模组端、后装etc 设备的报文信息，来自其他车辆设备端的数据不予处理；后装车载etc设备标 识代码是标识当前报文信息的源端口为后装车载etc设备端。另外，最后的消 息内容报文段又分为两种消息内容格式：写请求标识代码、应答消息类型标识 代码。而且，
[0110][0111]
表2-1
[0112]
后装etc设备写入数据内容主要是两种：一种是在接收到车机设备端发送 读请求后，后装etc设备会根据收到的读请求类型来决定发送回车机设备端的 报文数据类型，具体地，如果是请求后装etc设备的剩余电量的，则生成剩余 电量的报文格式，其报文字段格式如表2-2所示；如果是请求车辆的通行信息 的，则生成当前通行信息的报文格式，其报文字段格式如表2-3所示。另一种 是在车辆通过高速公路出口etc收费站时刻后，后装etc设备会根据收到的 rsu设备的实际扣费来决定发送会车机设备的报文数据类型，如表2-4所示， 包括：预付费实际扣费日期时间、app应用名称、app运营商名称、购买当前 付费业务的实际扣费金额，当然，也可包含app运营商银行账户信息，但这个 信息较为敏感，用户也没有关注app运营商银行账户的必要，所以在待发送的 数据内容中app运营商银行账户信息可以被裁剪。
[0113]
1字节长度：0xf12字节长度读请求标识代码剩余电量(0-100)
[0114]
表2-2
[0115][0116][0117]
表2-3
[0118][0119]
表2-4
[0120]
另外，每一个写请求数据指令报文在发送之后都要等待接收方的一个应答 消息。
如果是车机设备端发出的数据指令报文，则需要等待后装etc设备端的 应答，后装etc设备发送给车机设备端的应答消息的报文格式如表2-5所示， 应答消息内容格式比较简单，标识代码占一个字节长度，实际应答消息占一个 字节长度，如果当前流程节点操作成功，则发回成功的应答响应，用16进制 0x32表示；如果当前流程节点操作失败，则发回失败的应答响应，用16进制 0x01表示。同样地，如果是后装etc设备端发出的数据指令报文，则需要等 待车机设备端的应答。
[0121][0122]
表2-5
[0123]
在一个具体实施例中，结合图6，后装etc设备在系统启动后进入就绪状 态，并时刻检测是否处于高速公路计费状态，如果正处于计费状态，则说明当 前车辆已经行驶在收费高速公路上，此时后装etc设备会检查自身内部缓存区 是否有待处理的预付费信息，如果车辆没有处于计费状态或者是缓存区没有预 付费数据，则开始监听dsrc端口是否有数据输入。如果处于计费状态，且缓 存区内有预付费信息数据，则将该预付费缓存交易信息读取出来，然后写入到 后装etc设备的高速公路计费清单中，接下来开始监听dsrc端口，等待高速 公路etc收费站rsu做扣费操作。
[0124]
后装etc设备的dsrc端口会有三种形态的数据输入：1.车机设备端发送 过来的请求，读取剩余电量或通行信息；2.车机设备端发送过来的预付费信息， 用户购买了车机付费app的对应服务产生的预付费数据报文；etc路侧端rsu 设备扣费之后发送的应答信息，用于表示实际扣费操作是否成功。
[0125]
对于第1种数据输入，将获取剩余电量信息或通行信息，然后针对车机端 发过来的请求生成对应的回复报文，报文格式参考表2-1、2-2、2-3，然后 将其发送到dsrc端口。
[0126]
对于第2种数据输入，首先将预付费信息写入本地缓存数据库中，形成预 付费缓存数据，然后根据操作结果发送应答报文给车机，其应答报文格式如表 2-5所示。
[0127]
对于第3种数据输入，首先根据rsu设备传递过来的信息来判断实际扣费 有没有成功，如果得到失败的扣费结果，则不做任何处理，并回到开始的程序 入口重新开始；如果判断出实际扣费成功，则此时需要主动向车机设备端报告 这个情况，具体地，将之前缓存的预付费信息提取出来，然后封装成如表2-4 所示的数据报文格式，并将其发送到dsrc端口。实际扣费反馈信息发送给车 机设备端之后，后装etc设备端还需要等待车机设备端的应答报文，从而确保 两端对预付费信息的记录和处理都保持一致。如果得到成功的应答报文，则清 掉自身的预付费缓存消费信息，然后回到程序开始的循环入口；如果得到失败 的应答报文，则重新发送实际扣费反馈信息数据报文到车机设备端，直到接收 到成功的应答ack报文。
[0128]
本发明还构造一种车机设备，包括第一处理器及存储有第一计算机程序的 第一存储器，该第一处理器在执行所述第一计算机程序时实现以上车机设备与 后装etc设备的通信方法(运行在车机设备中)的步骤。
[0129]
图7是本发明实施例提供的车机设备的示意性框图，该实施例的车机设备 700可以为车辆上的中控设备，还可为智能手机、平板电脑、笔记本电脑、台 式电脑、个人数字助理和穿戴式设备等具有通信功能的电子设备。
[0130]
参阅图7，该计算机设备700包括通过系统总线701连接的第一处理器 702、第一存储器和第一网络接口705，其中，第一存储器可以包括非易失性 存储介质703和第一内存储器704。
[0131]
该非易失性存储介质703可存储操作系统7031和第一计算机程序7032。 该第一计算机程序7032包括程序指令，该程序指令被执行时，可使得第一处 理器702执行上述车机设备与后装etc设备的通信方法(运行在车机设备中)。
[0132]
第一该处理器702用于提供计算和控制能力，以支撑整个车机设备700 的运行。
[0133]
该第一内存储器704为非易失性存储介质703中的第一计算机程序7032 的运行提供环境，该第一计算机程序7032被第一处理器702执行时，可使得 第一处理器702执行上述车机设备与后装etc设备的通信方法(运行在车机设 备中)。
[0134]
该第一网络接口705用于与其它设备进行网络通信。本领域技术人员可以 理解，图7中示出的结构，仅仅是与本技术方案相关的部分结构的框图，并不 构成对本技术方案所应用于其上的车机设备700的限定，具体的车机设备700 可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的 部件布置。
[0135]
本发明还构造一种后装etc设备，该后装etc设备包括第二处理器及存储 有第二计算机程序的第二存储器，该第二处理器在执行所述第二计算机程序时 实现以上车机设备与后装etc设备的通信方法(应用于后装etc设备)的步骤。
[0136]
图8是本发明实施例提供的后装etc设备的示意性框图，该实施例的后装 etc设备800包括通过系统总线801连接的第二处理器802、第二存储器和第 二网络接口805，其中，第二存储器可以包括非易失性存储介质803和第二内 存储器804。
[0137]
该非易失性存储介质803可存储操作系统8031和第二计算机程序8032。 该第二计算机程序8032包括程序指令，该程序指令被执行时，可使得第二处 理器802执行上述车机设备与后装etc设备的通信方法(运行在后装etc设备 中)。
[0138]
第二该处理器802用于提供计算和控制能力，以支撑整个车机设备800 的运行。
[0139]
该第二内存储器804为非易失性存储介质803中的第二计算机程序8032 的运行提供环境，该第二计算机程序8032被第二处理器802执行时，可使得 第二处理器802执行上述车机设备与后装etc设备的通信方法(运行在后装 etc设备中)。
[0140]
该第二网络接口805用于与其它设备进行网络通信。本领域技术人员可以 理解，图8中示出的结构，仅仅是与本技术方案相关的部分结构的框图，并不 构成对本技术方案所应用于其上的车机设备800的限定，具体的车机设备800 可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的 部件布置。
[0141]
本发明还构造一种通信系统，该通信系统包括以上所述的车机设备及后装etc设备。
[0142]
以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领 域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则 之内，所作的任何纂改、等同替换、改进等，均应包含在本发明的权利要求范 围之内。