车载智能无线网络反向控制系统的制作方法

1.本发明涉及的是一种车辆远程控制领域的技术，具体是一种车载智能无线网络反向控制系统。


背景技术：

2.现有智能网联汽车网络系统涵盖三大组成部分，分别是车载终端、数据中心和手机客户端。其中车载终端一是基于车内网络实现车内传感器的信息采集、车内娱乐与安全防护多种业务，二是实现车内网与移动网络或车联网的通信业务。目前实现车内信息采集的车内网基于有线连接，包括基于本地互联网络(local interconnect network,lin)总线架构、基于can总线架构、基于flexray总线架构以及基于most总线架构，基于无线通信方式实现车内信息采集的研究还比较少。


技术实现要素：

3.本发明针对现有技术存在的上述不足，提出一种车载智能无线网络反向控制系统，通过利用zigbee的mesh网状网络拓扑结构，实现网络各节点的星型和多跳型方式通信，针对性地解决布线问题、功能的集成时间以及系统的升级可拓展性，达到能灵活控制车内模块，实现远端的人车信息交互和控制。
4.本发明是通过以下技术方案实现的：
5.本发明涉及一种车载智能无线网络反向控制系统，包括：位于用户端的移动交互单元、位于服务端的指令接收单元、指令校验单元、指令转发单元和指令信息存储单元以及位于车载控制端的车载应用处理单元(application processing unit，apu)以及zigbee组网单元，其中：用户通过移动交互单元设置控制指令并发送至服务端，经服务端依次进行指令接收、校验及转发至车载控制端，车载应用处理单元接收来自服务端的控制指令，由zigbee组网单元根据指令类型实现对车内部件的控制。
6.所述的zigbee组网单元接收来自车载应用处理单元的指令并进行路由转发和部件控制，该zigbee组网单元包括：用于控制指令验证以及指令转发的协调器节点、终端节点和路由节点，节点间通信的传输方式包括有点对点模式以及广播模式，协调器节点根据每个指令数据包中的指令类型，经过不同的路由节点找到对应的终端节点，其指令类型和终端控制节点地址的映射关系存储在协调器节点中；终端节点根据不同的应用服务挂载不同的部件并进行部件控制。技术效果
7.本发明整体上是针对现有车内服务模组(如空调、车门、灯光等)的日益复杂，解决复杂的有线连接造成的车内布线困难、功能集成时间增加以及系统升级可拓展性变差的问题。在保证可容忍的服务体验的情况下，对车内有线组件部分进行升级改造为无线连接，同时考虑无线连接带来的传输指令丢包和指令误传的问题，增加了指令失败反馈机制，防止指令错误指令导致的控制紊乱的问题，以保证系统运行的稳定性。
附图说明
8.图1为实施例应用场景示意图；
9.图2为app指令转发流程图；
10.图3为服务器指令接收、处理及转发流程图；
11.图4为协调器路由、转发及控制流程图；
12.图5为实施例网络拓扑示意图。
具体实施方式
13.如图1所示，为本实施例涉及一种车载智能无线网络反向控制系统，包括：位于用户端的移动交互单元、位于服务端的指令接收单元、指令校验单元、指令转发单元和指令信息存储单元以及位于车载控制端的车载应用处理单元以及zigbee组网单元，其中：用户通过移动交互单元设置控制指令并发送至服务端，经服务端依次进行指令接收、校验及转发至车载控制端，车载应用处理单元接收来自服务端的控制指令，由zigbee组网单元根据指令类型实现对车内部件的控制。
14.所述的车载apu和zigbee组网之间采用的是异步收发(universal asynchronous receiver/transmitter，uart)方式进行通讯。
15.所述的移动交互单元包括：用户登录界面、用户控制界面，其中：用户登录界面用于用户验证信息的验证，避免他人非法操作用户车辆；用户控制界面用于用户指令转发。
16.所述的用户指令包括：车内空调控制指令、车门控制指令。
17.如图2所示，所述的验证是指：用户登录界面通过不断扫描控件，并在用户发出控制指令时对指令进行解析对比，通过设定的不同指令来实现不同的功能，解析成功则实现指令转发，通过okhttp传输协议转发至服务器端进行中转。
18.所述的服务端中的指令接收单元、指令校验单元、指令转发单元和指令信息存储单元，其中：指令接收单元通过okhttp协议实现用户的请求和响应的接收，指令校验单元在传输过程中对可能因外部环境干扰而导致乱码的指令进行校验，指令转发单元将校验后的指令进行解析并封装转发至车载apu，指令信息存储单元保存服务端每次的控制指令信息于云端的数据库中，通过浏览器或ui界面实时查看对应的历史记录，每条历史记录都保存着对应的控制指令类型、控制指令功能以及控制的时间戳。
19.如图3所示，所述的校验是指：指令接收单元接收来自app端的数据包，指令校验单元进行指令解析，同时对此时的指令进行保存至本地数据库，用以查看每次对车辆发出的控制指令，解析成功后的指令通过封装转发至车内的apu模块。
20.所述的校验是指：对接收的控制指令的每个字段按照规定特定的指令格式协议进行字段校验，不同的指令功能对应不同的数据格式，以此作为避免错误指令触发的预判操作。
21.所述的车载控制端中的车载应用处理单元对来自服务器端的封装数据进行接收、校验以及通过串口转接到协调器转发，其中：接收和校验部分服务器模块一致，目的是充分在每个模块保证数据的安全性，转发部分是apu通过串口转接到协调器实现的，此模块是实现服务端指令的接收以及预处理，同时转发指令给通过串口连接的zigbee组网单元的协调器节点。
22.所述的zigbee组网单元接收来自车载应用处理单元的指令并进行路由转发和部件控制，该zigbee组网单元包括：用于控制指令验证以及指令转发的协调器节点、终端节点和路由节点，节点间通信的传输方式包括有点对点模式以及广播模式，协调器节点根据每个指令数据包中的指令类型，经过不同的路由节点找到对应的终端节点，其指令类型和终端控制节点地址的映射关系存储在协调器节点中；终端节点根据不同的应用服务挂载不同的部件并进行部件控制。
23.如图4所示，所述的部件控制是指：zigbee的协调器节点通过对目标节点进行路由寻址找到目标终端节点，此节点接收到对应的指令进行指令实现，操作电机正反转、开启或停止。
24.所述的协调器节点、路由节点以及终端节点在网络地址上的划分分别为：0x0000，0x0001
‑
0x7fff以及0x8000
‑
0xffff，其网络拓扑如图5所示，不同的终端节点对应着不同的网络地址，所以各节点挂载的控制应用不同，对应的节点地址也不同。如图所示，当终端节点的0x8000挂在的应用服务为空调开关，则将空调的控制指令格式与空调所在终端节点的地址0x8000的映射关系存入在协调器节点中，协调器通过接收到的指令格式与映射表中比较，根据找到的目标节点地址进行路由转发，准确实现对某一节点的控制。本场景中其控制指令格式与目标节点地址映射表关系如表1所示。
25.表1控制指令与目标地址映射表指令类型指令功能目标地址airon/off0x8000dooron/off0x8001air_adjustup/down0x8000windowup/down0x8002
26.针对车载zigbee无线网络控制的方案，其指令在传输过程中可能由于无线环境因素干扰存在丢包风险，从而可能导致控制功能丧失，甚至终端控制模块失控现象。因此，针对终端节点接收到的控制指令需要提前校验，如表2所示，该数据包为空调开关控制数据包，其数据头标识为。每个终端节点通过挂载的不同控制器件实现不同的控制功能，所以其终端节点处理单元保存的是对应控制指令，根据终端节点接收到的控制指令进行提前校验，若成功，则执行对应的控制器，若失败，则采用失败控制机制。
27.表2空调开关数据包数据头控制类型控制功能校验位0xaa0x010x01crc
28.所述的失败控制机制包括：
29.1)丢弃反馈：接收的指令校验失败后，会立即丢弃该控制指令，同时向上反馈控制失败的提示数据包，通过协调器转发给apu，apu发回给服务器端，最终反馈到用户的ui界面，提示用户操作失败信息。
30.2)失败重传：接收的指令校验失败后，会发送一段反馈数据包给协调器，协调器接收到反馈后会自动重新发送，设置重传次数上限，若持续重传失败，则丢弃该控制指令，同时向上反馈给用户端。
31.所述的部件包括但不限于实现空调开关、远程开关锁的电机模块，该电机模块优
选采用型号为28byj的五线四相步进电机。其驱动方式是通过将电脉冲转化为角位移来实现转动，通过控制脉冲个数来控制角位移量，从而达到精准定位的目的，通过控制脉冲频率来控制电机转动的速度，从而达到调速的目的。具体对于五线四相电机的通电方式如下表2，其为逆时针旋转相序图。
32.如表3所示，通过给五线四相电机的各线按上表相序规则通电，可以使得电机逆时针旋转一周，以此模拟车内车门张开的角度的控制，通过控制电机的旋转角度从而使得能控制车门张开的角度。同样，想要使得电机按照顺时针旋转某个角度，可以通过电机的顺时针旋转表进行电平设置，从而达到顺时针旋转的目的。
33.表3电机的驱动方式
34.如表4所示，本实施例以步进电机模拟车内空调控制为例，通过用户端设置如表3所示的指令，通过okhttp协议转发至服务端处，服务端解析获取到指令，将指令继续转发至车载apu上，同时将指令存储至本地数据库中。
35.表4指令控制表
36.如表5所示，app端控制指令转发至服务器，对应存储的是控制指令类型，指令功能以及指令发出时间。
37.表5服务端指令接收记录id指令类型指令功能指令时间1airon/offcurrent_time2dooron/offcurrent_time﹒﹒﹒﹒﹒﹒﹒﹒﹒﹒﹒﹒nair_adjustup/downcurrent_time
38.在组网基础上，首先对每个终端节点记录数据包的传输次数，设定固定的传输次数上限用来终止传输；其次对协调器接收的所有数据包进行识别，同时记录接收符合传感器数据格式数据包的次数，最终得到整个组网的丢包率其中：send是指zigbee的每个终端需要发送的包数，reve是指zigbee的协调器节点接收的总包数，n是终端节点有多少个作为发送点。
39.统计从app端到服务器，再到apu，最后到车内终端控制链路的时间消耗，从app端发出指令，服务器接受转发至apu，最后通过协调器路由寻址控制车内某个终端节点。其控制时延delay＝mcu
delay
server
delay
app
delay
，其中：mcu表示从协调器节点发送信号至某一终端节点的时间，server表示服务端接收到来自app端信号转发至apu的时间，最后的app是从用户发出指令到服务端接收到信号的时间。
40.本实施例模拟app远程控制车内电机，统计从用户发出指令到指令执行的时间，由表中看出，此时延的平均范围是处于秒级别，能基本满足用户对车内终端的控制体验，在实验室环境中模拟了指令从app端发给服务器，再通过apu接收中转，传送至车内终端控制链路，从而实现对某个节点的控制场景。其中安卓手机一台，数据中心服务器一台，车内模块apu(型号)一台，zigbee组网模块一套(协调器节点：一个，路由节点：2个，控制节点：3个)。
41.如表6所示，为实验场景下，协调器与目标终端节点之间数据包的发送和接收的统计数据，由表中看出四组实验数据的丢包率不超过百分之一，最低时基本不丢包，最高时其丢包率达到0.6％，其产生数据丢包可能造成原因为实验室环境下同频段的wi
‑
fi网络干扰。
42.表6zigbee组网丢包率终端控制节点数量发送(包数)接收(包数)丢包率(％)310010003200200035004980.4310009940.6
43.如表7所示，为实验场景下测得的四组系统控制时延结果，充分考虑车内控制部分的移动性，其中每组情况下车内控制组件分布不一，并且每组结果是在同一时间段内连续发出10次控制指令得到的时延均值，由表中看出，其在两种指令类型(on/off)下的平均时延范围是处于秒级别，能基本满足用户对车内终端的控制体验，同时也解决了车内由有线连接带来的问题。
44.表7系统控制时延指令类型onoff10.97s1.07s21.32s1.36s31.15s1.85s41.27s1.42s
45.上述具体实施可由本领域技术人员在不背离本发明原理和宗旨的前提下以不同的方式对其进行局部调整，本发明的保护范围以权利要求书为准且不由上述具体实施所限，在其范围内的各个实现方案均受本发明之约束。