您好,欢迎来到九壹网。
搜索
您的当前位置:首页一种车载终端软件架构及实现

一种车载终端软件架构及实现

来源:九壹网
一种车载终端软件架构及实现

张远;何袁全;张宁

【摘 要】车载终端是车联网系统的重要组成部分, 为了提高终端软件的可靠性和开发效率, 参考 NGTP(Next Generation Telematics Pattern),设计了一个开放式的车载终端软件架构.在该架构中,系统由移动终端、后台支撑系统、车载终端及后台业务系统组成, 各部分之间通过标准数据协议进行数据交换, 实现车辆远程数据采集和诊断、紧急情况处理、远程查询及控制等车联网典型应用. 为了提高终端软件系统的可靠性, 将终端软件分解成功能系统与守护系统两部分, 通过守护系统实时监控功能系统, 当功能系统出现故障时, 重新启动功能系统来保证终端软件系统的有效性. 根据该架构开发的车载终端验证了方案的有效性.%Vehicle Terminal is an important part of the IOV(Internet of Vehicle). To improve the reliability and development efficiency of the Terminal software architecture, we designed, referring to NGTP (Next Generation Telematics Pattern), an opening software architecture for the vehicle terminal, in which the IOV system consists of several parts, mobile terminal, background support system, vehicle terminal and background process system. Every part of the IOV system exchange data according to the standard data protocol to complete some typical applications of the IOV, such as remote data acquisition and diagnosis, emergency treatment ,remote query and control, etc. The terminal software is decomposed into two parts ,function system and guardian system, to improve the reliability. Real-time monitored by the guardian system, the function system will be rebooted upon it

breaking down. And the feasibility was verified by the vehicle terminal designed according to this architecture. 【期刊名称】《计算机系统应用》 【年(卷),期】2015(024)008 【总页数】4页(P137-140)

【关键词】车载终端;软件架构;NGTP;守护系统 【作 者】张远;何袁全;张宁

【作者单位】重庆邮电大学自动化学院,重庆 400065;重庆邮电大学自动化学院,重庆 400065;重庆邮电大学自动化学院,重庆 400065 【正文语种】中 文

车联网是物联网技术在智能交通系统中的应用, 它提供与车辆安全相关的远程控制服务, 远程车辆定位[1], 车况查询等, 是重点关注的服务类型. 同时智能手机应用到车联网服务中, 成为一种发展趋势. 现有的OnStar手机应用包括车况, 遥控, 助手三大服务, 其中遥控包括远程车门锁的开启与关闭, 远程启动车辆, 远程双闪灯或鸣喇叭(提示车辆位置). 目前这类应用的系统架构主要有C/S(Client/Server) 架构[2]和B/S(Browser/Server)架构. 相比于C/S架构, B/S架构的客户端简化成一个Web浏览器, 相应的逻辑被集中起来, 置于远程服务器上, 减少了维护成本, 这样系统更稳定. 但使用的简单网络管理协议对于查询以及返回的数据包等格式没有明确定义, 不标准; 采用C/S架构, 用户通过控制台发出控制命令, 经控制中心转发给被控设备, 执行控制命令, 系统架构针对特定需求而设计, 不开放. 总之, 不论是C/S架构, 还是B/S架构, 这类系统架构和协议均是针对特定的需求而设计和制定的, 存在着架构不

开放, 协议不标准问题, 需求改变后则系统需重新设计, 这样资源得不到共享, 系统适应能力差,可重用性不强, 增加了开发成本.

要实现以上设计目标, 就必须为软件系统的体系组织建立合理的软件架构以指导与保障复杂软件系统的最终实现. 针对上述问题, 参考国际上典型的开放标准NGTP, 设计一个开放式车联网载终端系统软件架构, . 在终端软件架构方面, 将其分解成功能系统与守护系统两部分, 通过守护系统实时监控功能系统来提高终端软件系统的可靠性.

软件架构(Software Architecture)是一系列相关的抽象模式, 是一个系统的草图, 用于指导大型软件系统各个方面的设计. 软件架构描述的对象是直接构成系统的抽象组件. 各个组件之间的连接则明确和相对细致地描述组件之间的通讯. 在面向对象领域中, 组件之间的连接通常用接口来实现. 软件架构设计[3]的目标是要设计出可靠性(Reliable)、安全性(Secure)、可扩展性(Scalable)、可维护性(Maintainable)等特性的软件系统.

由于现有的车联网系统均是针对特定类型车辆而开发的, 系统开放性不强, 协议不统一, 并且目前还没有关于车联网架构方面的标准, 也没有完整的相关数据交换接口标准. 本文对现有的车联网系统需求进行分析, 引出本文所设计的系统需求, 并参考国际上开放的车联网已有架构NGTP, 针对NGTP架构中缺少对远程移动终端支持的情况, 增加移动终端, 作为接入系统的接口, 提出一个开放式车联网系统软件架构, 同时制定系统的通信协议. 该架构解决了系统不开放的问题, 提高了系统的通用性, 这样资源能够得到共享, 减少了开发成本. 1.1 系统的整体框架设计

本系统参考NGTP架构, 框架的三个主要部分组成: Telematics单元(TU), Telematics服务供应商(TSP)和调度器(DSPT). 针对NGTP架构不支持监控终端的接入, 在它的基础上进行简化, 增加移动终端模块, 其中移动终端是用户和后台服务

系统的交互工具, 作为用户接入系统的客户端. 整个系统如图1所示, 包括车载终端, 后台服务系统, 移动终端三个部分: 其中移动终端包括智能手机, 平板电脑, 笔记本电脑等; 后台服务系统包括Dispatcher, ServiceHandler, 数据库; 车载终端模块包括应用软件层, 监视系统, 中间层, 操作系统系统内核层, 硬件驱动层.

车载终端, 相当于NGTP中的TU(Telematics Unit,车载器), 它是车联网的重要组成部分, 它包括硬件, 驱动软件, 通信软件及其他应用软件等, 承担车内实时网络与外部移动网络信息交互, 而且集成了多种应用[4]. 它是面向用户服务的第一界面, 也是系统服务和信息流的起始点, 为了实现对车身多个传感器的信息融合, 终端增加了对CAN模块的支持, 而检测车辆状态信息的多个传感器则通过车载CAN网络传递到终端, 再由终端经过融合处理后, 通过网络传输到后台服务系统, 相应的控制命令也可以通过网络传输到车载终端, 再通过CAN网络传输到车辆具体的控制器, 对车辆进行远程控制等.

后台服务系统包括Dispatcher, ServiceHandler及数据库. Dispatcher接收车载终端软件上传的数据, 存入数据库, 并分发数据给车载终端和ServiceHandler. 它主要是将车辆运行状况数据存储在数据库中, 同时对数据进行分发. Dispatcher跟NGTP架构中的Dispatcher在调度数据方面功能是相同的, 它是移动终端、数据库和车载终端之间的通信接口. 负责将相关的信息路由到指定的模块, 并将接收的数据存储到数据库中, 同时转发相应指令. ServiceHandler跟NGTP架构中的ServiceHandler在分发数据方面功能是相同的, 为移动终端访问及远程监控车辆的通信接口. 它接收来自移动终端的指令, 并转发给Dispather, 同时接收来自Dispatcher的数据转发给移动终端. 数据库的功能是用来存储车辆状态信息和车辆属性信息, 供查询及诊断等使用, 便于对信息进行管理, 保护数据的安全性. 移动终端是新增的模块, 即移动通信终端, 其移动性主要体现在移动通信能力和便携化体积方面, 主要包括智能手机, 平板电脑, 笔记本电脑三类, 是用户接入系统的

接口. 用户借助移动终端软件可以与后台的ServiceHandler之间进行通信, 发出相应的指令.

2.1 车载终端系统稳定性的改进

车载终端是车联网系统的关键部分,为了提高终端软件系统的可靠性, 在终端软件架构方面, 将终端软件分解成功能系统与守护系统两部分, 通过守护系统实时监控功能系统, 当功能系统出现故障时, 重新启动功能系统来保证终端软件系统的有效性. 本系统是基于Android系统的开发, 考虑到影响系统稳定性能的众多影响, 提出了一种利用Android系统自带的Content Provider组件设计的辅助机构监控系统运行的方案, 当该系统因某种故障停止运作或进入其他不良工作状态(如进入程序死循环), 辅助机构将其重新启动继续运行. 要实现以上设计目标, 就必须为软件系统的体系组织建立合理的软件架构以指导与保障复杂软件系统的最终实现, 终端系统的软件架构改进方案如图2所示.

如图2, 监控子程序用Service实现, 监控子程序的Service由车载主程序中的Broadcast发送的启动广播启动. Service启动后, 随即在内部创建一个ContentProvider, 并封装查询(Query)、修改(Update)、删除(Delete)、插入(Insert)方法, 此外还设置一个标志位变量. 同时还设置一个ContentObserver内容监视器用以检测标志位变量的变化, 一旦检测到变化就调用Update方法, 将变量复原.

在车载主程序中设置每5秒钟修改ContentProvider中设置的变量. 在监控程序中, 当超过5秒钟没有检测到变量变化, 再次检测, 若5秒之后仍没有变化, 就可认为主程序出现故障, 发送重启广播重启主程序. 监控子程序实现程序流程图如图3. 图3是监控子程序的运行流程, 主程序在启动之后, 除了完成本身的工作, 另外每隔5s将监控子程序中创建的标志位由“0”变为“1”(主程序第一次启动是自主启动, 此后则都是由监控子程序发送的重启广播启动).

监控子程序接受主程序发出的启动广播后启动, 同时在内部创建一个

ContentProvider内容提供者, 并封装需要的Query、Update、Delete、Insert方法. 同时绑定一个ContentObserver内容监视器, 在ContentProvider内部创建一个标识变量初始化为“0”.

车载主程序调用Update方法修改标识变量为“1”.

ContentObserver检测到变量改变后, 调用Query方法查询变量, 并判断是否为“0”. 若不是, 说明主程序修改成功, 车载程序运行正常; 若是, 则说明主程序修改失败, 在等待5S再次查询变量, 并判断是否为“0”, 若不是, 则说明程序运行正常; 若是, 则说明程序修改失败, 主程序运行故障.

当判断主程序出现故障后, 监控子程序用Broadcast发送重启广播, 重启主程序. 系统测试以实车作为试验载体, 我们用远程查询和远程控制及可靠性测试三个应用去测试系统的响应时间以及成功执行情况. 远程查询主要是查询车辆的车身状态信息, 远程控制主要是通过WebServer控制车窗和车灯等, 可靠性测试是人为使得终端功能系统停止向守护系统发送心跳信息而导致守护系统计数器溢出, 观察监控系统能否成功重启终端系统.

本系统运行访问服务器, 将Dispatcher和数据库以及WebServer装在PC机上, 终端程序和监视程序运行在车载终端上, 在服务器上启动业务处理程序和Tomcat, 设置IP地址, 终端和服务器可以相互通信, 通过手机输入服务器IP地址, 登上WebServer, 这样就可以通过网页发出查询和控制命令, 以推送网页的形式将执行的结果返回. 如下表1所述, 实验结果表明查询的响应时间在3s左右, 远程控制的执行时间在2s之内, 终端系统重启时间在1秒之内, 成功执行率接近100%, 系统的实时性和可靠性较好, 亦说明了系统的可行性.

1 Lin CL, Hsieh MS, Tzeng GH. Evaluating vehicle telematcis system by using a novel MCDM techniques with dependence and feedback. Expert

System with Application, 2010, 37(10): 6723–6736.

2 钟新跃.基于C/S架构的停车场车位信息发布于管理系统. 计算机测量与控制,2013,21(7):1957–1962.

3 温昱.软件架构设计.北京:电子工业出版社,2007.

4 黄昌映,岑明,杨凡弟,李永福.开放式车辆远程控制架构研究及应用.计算机测量与控制,2014.

因篇幅问题不能全部显示,请点此查看更多更全内容

Copyright © 2019- 91gzw.com 版权所有 湘ICP备2023023988号-2

违法及侵权请联系:TEL:199 18 7713 E-MAIL:2724546146@qq.com

本站由北京市万商天勤律师事务所王兴未律师提供法律服务