基于电动客车远程控制协议的解析系统设计与实现

2021-03-09 09:41李祥冯拔叶标刘凯
新型工业化 2021年1期
关键词:控制协议报文客车

李祥,冯拔,叶标,刘凯

(长沙中车智驭新能源科技有限公司网联应用技术部,湖南 长沙 410006)

0 引言

在政策和技术进步的共同推动下,全球电动客车市场迅速发展,今年由于新冠肺炎疫情的影响,增速有所放缓,但对于出行交通的安全化、舒适化要求却越来越高,因此整车厂在生产车辆的同时,也必须开发相应的网联化平台,电动客车远程控制平台正是在此背景下应运而生的[1-2]。

现有的GB/T 32960-2016《电动汽车远程服务与管理系统技术规范》,规定了车载终端上传到国家监控平台的数据格式及内容,而电动客车远程控制平台在此基础上,进行了自定义的拓展。电动客车远程控制平台在实际开发过程中,调试人员需要对照电动客车远程控制协议进行人工比对解析,导致耗费大量的时间且容易出错。

针对上述存在的问题,本文结合电动客车远程控制协议,设计并开发了电动客车远程控制协议解析系统。该系统包括系统架构设计、系统功能设计、系统数据库设计以及系统主要功能实现。在实际的解析过程中,此系统完美地解决了数据报文解析,提高了工作效率。

1 系统概述

电动客车远程控制协议用来规范车载远程监控终端与电动客车远程控制平台端间通信数据格式[3],操作移动手机端进行车况查看、车辆部件控制、一键诊断等。其中,数据单元部分内容为:第三链路状态查询数据单元、第三链路状态设置数据单元、远程车辆控制数据单元、车辆部件控制状态反馈数据单元、车辆部件状态数据单元、一键诊断数据单元。电动客车远程控制协议的数据包结构及定义如表1所示。

表1 数据包结构及定义

电动客车远程控制协议解析系统除了对车载远程监控终端与电动客车远程控制平台通信的数据报文进行解析,还包括对十六进制转换为文本字符串、十六进制转换为日期、十六进制转换为十进制等功能。调试人员通过CAN网络采集电动客车远程控制协议报文后,将数据包报文在WEB端电动客车远程控制协议解析系统进行解析,待解析完后将报文结果可视化展示。

2 系统总体设计

2.1 系统架构设计

电动客车远程控制协议解析系统软件架构采用三层体系结构[4],包括数据展示层、数据处理层、数据存储层,体系结构如图1所示。

图1 体系结构

数据展示层:用户将采集数据输入到前台页面的文本域,点击提交按钮提交请求到服务端的后台,后台处理完后把结果返回给前台数据页面。数据展示层运用HTML、CSS、BootStrap、JavaScript等技术,将后台的处理结果渲染到前台页面。

数据处理层:服务端接受前台传递过来的报文数据,根据电动客车远程控制协议,识别命令指令,包括第三链路状态查询、第三链路状态设置、远程车辆控制、车辆部件控制状态反馈、车辆部件状态等指令,从而进行数据处理。

数据存储层:在数据处理的过程中,既包括原始报文数据的持久化到MYSQL数据中,又包括实际业务数据的持久化,将数据持久化到磁盘中,避免数据的丢失。

2.2 系统功能设计

电动客车远程控制协议解析系统主要是帮助开发与调试人员快速解析远程控制报文,其主要功能包括第三链路状态查询报文解析、第三链路状态设置报文解析、远程车辆控制报文解析、车辆部件控制状态反馈报文解析、车辆部件状态报文解析、一键诊断报文解析以及进制转换功能,功能设计如图2所示。

图2 功能设计

第三链路状态查询包括参数设置时间、参数总数、参数项列表,第三链路状态设置也包括参数设置时间、参数总数、参数项列表。

远程车辆控制报文解析包括时间、命令ID、命令参数,其中命令参数包括车辆启动、车辆熄火、车前门开、车前门关、车后门开、车后门关、车中门开、车中门关、空调开、空调关、小灯开、小灯关、近光开、近光关、远光开、远光关、锁车、解锁、电加热开启、电加热关闭、喇叭开启、喇叭关闭、驾驶模式、限制车速、限制驱动功率、车辆蠕行开启、车辆蠕行关闭、双闪开启、双闪关闭、开始一键诊断、停止一键诊断。

车辆(部件)控制状态反馈内容包括控制指令下发时间、命令ID、控制响应状态、命令状态描述,其中控制响应状态包括响应控制指令成功、响应控制指令失败、远程控制校验成功、远程控制校验失败、车身控制器未响应控制请求。

车辆(部件)状态包括数据采集时间、信息类型标志(1)、信息体(1)、信息类型标志(n)、信息体(n)。部件运行状态包括:模式、锁车、空调、电池加热、小灯、前大灯(近光)、前大灯、(远光)、前门、中门、后门、喇叭、驾驶模式、车速、驱动电机功率、车辆蠕行、车辆溜车制动百分比、车辆电制动响应速率、双闪、车辆驱动响应速率、启动熄火。

车辆诊断数据包括数据采集时间、诊断数据。其中诊断数据有灯光系统诊断状态、门控系统诊断状态、驱动散热系统诊断、驱动系统诊断、储能散热系统诊断、转向诊断、泵气系统诊断、空调诊断、灯光系统故障代码、门控系统故障代码、驱动散热系统故障代码、储能散热系统故障代码、驱动系统故障代码、储能系统故障代码、转向系统故障代码、泵气系统故障代码、空调系统故障代码、总体诊断状态。

2.3 系统数据库设计

电动客车远程控制协议解析系统数据库设计即数据表的设计,本系统主要涉及的表为:原始码流信息表(origin_data)、状态查询信息表(state_search)、状态设置信息表(state_setup)、远程车辆控制信息表(remote_control)、车辆部件控制状态反馈信息表(remote_control_feedback)、车辆部件状态信息表(vehicle_state)、一键诊断信息表(oneclick_diagnosis)。

2.4 流程设计

电动客车远程控制平台的数据报文有两个流向:上行和下行。上行是指车载终端到电动客车远程控制平台的通信,下行是指电动客车远控平台到车载终端的通信。无论是上行还是下行,对于电动客车远程控制协议解析系统来说,并无本质上的区别,用户在CAN网络采集到的数据报文,放到电动客车远程控制平台进行解析,流程如图3所示。

图3 流程设计

3 系统主要功能实现

本系统的具体实现过程中,选用Java语言作为开发语言,Idea作为开发工具,Maven作为Jar包管理工具,采用流行的SpringBoot、Mybatis等框架技术。本文对远程车辆控制报文解析、一键诊断功能进行详细的实现描述[5]。

远程车辆控制报文解析功能的实现,其主要流程为:采集报文、持久化报文、解析报文、展示结果。其中,采集报文的步骤为:首先通过CAN网络进行数据的采集,然后将采集到数据报文在WEB端的电动客车远程控制协议解析系统发起请求,请求到达RemoteControlController类上,进行原始报文数据的持久化、解析报文,最后将处理的结果返回给客户端。远程车辆控制报文解析功能实现如图4所示。

图4 车辆远程控制功能实现

对于一键诊断功能,将采集的数据报文放到电动客车远程控制协议解析系统文本输入框,点击解析按钮发送Ajax请求到后台,请求体中包含用户请求的参数(即数据报文),在后台的DiagnoseStatusController程序类及getFrontMsg(String orginData)方法上,贴上@RequestMapping注解用来处理请求地址映射,而后在方法里面进行实际的业务逻辑处理,处理完后将处理结果封装DiagnoseStatus对象中去,再借助Gson工具类把DiagnoseStatus对象转成json字符串,将结果返回给前台页面进行结果的渲染,如图5为一键诊断的具体实现。

图5 一键诊断功能实现

4 结论

本文在电动客车远程控制协议的基础上,对电动客车远程控制协议解析系统进行设计,包括架构设计、功能设计、数据库设计,并采用Java语言对功能进行了实现。目前,电动客车远程控制协议解析系统在实际的运用过程中,调试人员采集数据报文后将报文放到电动客车远程控制协议解析系统,能够很好地解析出协议的内容,满足实际的调试需求,提高了工作效率;同样,也对其他系统的设计与实现有很好的借鉴意义。

猜你喜欢
控制协议报文客车
基于J1939 协议多包报文的时序研究及应用
CTCS-2级报文数据管理需求分析和实现
浅析反驳类报文要点
客车难改下滑颓势
金龙客车的不凡履历
客车市场进入寒冬?
基于Cruise的纯电动客车动力系统匹配
基于控制协议弱点的隐蔽通信研究
一种基于软件定义的OFDM—PON控制协议
ATS与列车通信报文分析