基于车联网的车辆信息远程搜集数据系统

车联网的概念在20世纪60年代已经先后出现在美国、欧洲与日本等发达国家和地区，并先后发展起ITS、IVHS、RTI、VICS等车联网系统。在国内，全国第四届GPS运营商大会，车联网的概念被首次提出，得到广大专业人士的认同；在无锡举行的中国国际物联网大会上，国家将车联网列为我国重大专项第三专项中的重要项目，中国的车联网由此起步。到现今，一些供应商所提供的车载系统中，已经基本实现智能导航、保养预约、咨询查询等功能，更方便车辆出行，在一定程度上提高了驾驶体验。

车联网的发展除了能提供用户更好的驾驶体验，同时也应可以为汽车厂商或4S店等机构提供强大的后台数据反馈服务。这对他们的业务拓展以及服务延伸也是有意义的。有力的数据反馈能对车辆的突发异常状况有及时的响应，对分析车辆的维修质量提供依据；历史性的数据可以为特定的车种提供有针对性和个性化的维修保养服务。

论文提供了一个具备实时车况信息监听，车况异常报警以及行车数据记录等强大后台数据反馈功能的解决方案，即车载系统采集到车辆状况信息后将其上传至服务器，管理员可以登录本方案系统的信息中心，使用车况远程监听，异常情况远程抓获及车辆行车日志等功能广泛收集行车数据。通过对数据的主动分析，汽车厂商不但能为车主提供更高质量、更主动的车辆维护服务，并且可以明确掌握某款、某系列汽车的运行状况，这对车种的改进及优化都有明显的贡献，同时可以提高汽车厂商的生产效率，减少车辆的维护成本。

　　1 方案的框架分析

方案实现框架图，如图1所示。整个系统是由两个服务器/客户端（C/S）架构子网构成，车载系统与服务器构成通过GPRS网络构成车/服信息交互网；信息中心与服务器通过包括符合TCP/IP协议的多元网络组成信息交互网。鉴于开放网络欠缺安全性，两个子网络的信息交互使用加密的通信方案，保证通信数据的基本安全。

图1 方案实现框架图

　　2 方案的主要功能模块定义

2.1 车载系统功能定义

（1）作为反馈数据的来源，是信息中心进行上层服务所需基本数据的主要提供者，与OBD系统进行信息交互，实时获取汽车的最新状态信息。

（2）接受来自数据服务器的任务请求，被动进行特定汽车状态信息的数据反馈。

（3）根据设置以及故障定义法则，当检测出汽车系统发生异常时，把汽车异常信息及时主动地反馈到数据服务器。

（4）汽车行程信息实时记录的直接执行者，并定时向数据服务器上传行程记录，与数据服务器互相结合成为汽车行程记录的完整系统。汽车行程记录暂存于车载系统本地Flash区，Flash区的储存空间比较大，并有掉电保持功能，可以充当黑盒子作用，当汽车发生意外来不及上传异常情报时，依然可以把意外发生时的最新情报及时保存。

（5）支持通信加密，密钥交换等安全的相关机制。

2.2 数据服务器功能定义

（1）作为反馈数据共享者的核心角色。接收到的大量反馈数据提供结构化的数据存储。结构化的数据便于二次数据加工，并适合与不同意义数据的逻辑存储隔离。实现远程数据库服务器的功能。

（2）接受来自远程信息中心的数据访问，正确地执行来自信息中心的任务请求以及接受来自信息中心对车载系统节点进行数据访问的委托，委托机制能通过Cache机制，提高对信息中心请求的响应速度。

（3）接受来自车载系统节点信息，并根据一定的法则使用接受到的信息对数据库数据进行更新。并且代理完成来自信息中心委托对车载系统节点进行数据访问的任务。

（4）对信息中心以及车载系统节点提供认证服务，并提供数据访问控制等安全机制。

（5）支持通信加密，密钥交换等安全相关的机制。

2.3 信息中心功能定义

（1）作为对反馈数据进行深度应用的主要角色。 对数据服务器进行合法访问，并经过解析把数据转换成对管理员有意义的信息，包括车辆故障信息、车辆运行参数等。使用数据本地加工分析可以使通信采用浓缩了大量信息的代码通信，从而减少网络数据通信量，并减轻数据库的运算负担。

（2）提供信息中心的管理员对数据服务器进行远程合法操作的接口，包括获取信息请求、记录操作请求、登录认证、任务委托等基本应用接口，并通过软件抽象出远程汽车车况监听，远程车况异常及时响应等宏观应用层的功能。[page]

（3）支持通信加密，密钥交换等安全相关的机制。

　　3 方案可行性分析

3.1 车载系统方案实现可行性分析

车载诊断电路（ON-Board DiagnoSTics,OBD），它能够获取控制汽车的内部参数状态。OBD最初作为一种控制汽车排放的排量监视器，通过检测发动机状态和尾气中污染物的含量，提示驾驶员对车辆进行维护，后来逐步发展成一套完善的汽车综合监控系统。如果厂商实现了OBD标准中所有的PID功能，OBD可以提供胎压、空气流量、踏板位置等多方面的信息。

由于OBD系统无法通知用户错误的原因，需要把检测到的OBD数据发送给远程的厂商进行分析，然后再把信息反馈给用户。

通过OBD系统可以对汽车的状况有一个全面了解。标准的OBD提供了9种服务。

表1 标准OBD提供的服务

　　主要通过Model获取汽车当前的状态参数，比如胎压、电瓶电压、发动机转速、车速等。通过Mode3获取当前发生的故障码，通过Mode2返回与故障码相关的冻结帧。通过Mode7找到可能在以后会发生的错误码。

OBD协议支持多种物理，采用29 bit扩展CAN总线。OBD有4种通信桢，这4种通信帧在CAN协议上的实现如图2所示，图2（a）为点对点通信的格式，图2（b）为广播通信格式。

图2 OBD通信桢

采用ELM327作为与OBD通信的协议翻译器，该芯片支持ISO15764协议和对应的CAN总线物理层，ISO9141、ISO14230协议和对应的K-line物理层，SAEJ1850协议和对应的PWM&VPW物理层，将其转换为标准串口协议。使用ELM327可以提高通用性。采用SIM300作为GPRS通信模块，采用STM32F103RB作为车载端的主控芯片，128 kB的Flash可以满足故障信息存储的需要。

图3 车载系统框架图

3.2 服务器方案可行性分析

图4 服务器框架图

（1）数据服务器的网络通信采用标准的TCP/IP协议，数据传送采用面向连接的TCP模式。由于TCP/IP协议的广泛应用，绝大部分的网络设备都支持基于TCP/IP协议的网络传输，通信媒介不限于有线和无线。在软件层上，操作系统把对各种网络设备的数据通信抽象成Socket类，在软件编程上可以通过使用Socket类统一规范的接口操作数据服务器上的网络设备进行多元网络信息交互。

（2）数据服务器采用OLEDB技术，OLEDB把对多元数据库的操作抽象成统一规范的应用层接口，在软件编程上可以通过使用OLEDB类对数据库进行简单而规范化的数据操作，包括数据结构化存储、数据查询、数据更新等。

（3）数据服务器采用多线程（Multithreaded）的信息处理机制，多线程的信息处理技术，提高服务器对远程访问的实时响应性。对用于多用户的数据服务器系统，还可以通过多线程来技术来进行不同用户的信息处理的逻辑独立，让单个用户服务产生异常的情况下以最小的程度影响其他用户，保证了服务器的健壮性。[page]

3.3 信息中心方案可行性分析

图5 信息中心框图

（1）信息中心同样采用标准TCP/IP协议进行网络通信，软件编程上使用Socket类统一规范网络设备进行与数据服务器的网络通信，在TCP模式下进行的信息交互，使信息完整性有协议上的保障。

（2）使用外挂的数据解释库，对获取数据进行加工分析，便于软件的固件升级。

（3）事件机制来处理来自操作员的命令，提高软件对人机交互的实时响应速度。

        4 仿真验证

4.1 车载端仿真

车载端可通过OBD获取车辆信息并上传至服务器。

4.2 服务器仿真

在服务器端可保存有车辆信息和车主信息。配置好网络后，服务器可与信息中心互联，从而达到信息互传的目的。

图6 服务器端界面

4.3 信息中心仿真

管理员可通过登录信息中心查询车辆信息，如图7所示；进行故障处理，如图8所示；在线监测，如图9所示；设置监听项，如图10所示等。

图7 信息中心登录界面

图8 故障处理

图9 在线监测

图10 自定义监听

通过多项查询、监听项目，可以及时了解到车辆的状况并对其作出处理。

　　5 结束语

随着汽车使用的普及，做好汽车服务更是当下的重点。车载系统在客户服务方面将会逐步完善、人性化，但对作为车联网重要角色之一的汽车厂商的服务却仍未见起始。因此，方案的提出主要是面向汽车厂商，形成一个为汽车厂商服务的雏形，为如今国内刚起步的车联网的建设提供一个参考。在这基础上，各大厂商可与各运营商等形成一定的合作关系，完善汽车厂商的服务工作，共同促进车联网的建设。