浅谈交通部标准下的车辆监控系统平台关键技术.docx

浅谈交通部标准下的车辆卫星监控系统平台关键技术摘要：本文通过研究交通运输部于2011年颁布实施的强制标准道路运输车辆卫星定位系统平台技术要求及道路运输车辆卫星定位系统终端技术要求的技术要求，分析了车辆卫星定位监控标准系统建设的意义，研究行业标准系统平台建设的关键技术要点及处理方法。为交通运输部车辆卫星定位监控系统行业标准系统平台的建设提供技术方法建议。关键词：卫星定位 营运车辆 数据库 通信 分布式 聚合一、 引言目前GPS定位已被广泛应用于交通运输行业，它利用GPS的定位技术结合无线通信技术（GSM、CDMA、3G）、地理信息管理系统（GIS）等高新技术实现对车辆的监控，通过无线数字通道将车辆定位和状态信号输送到车辆监控中心，然后通过GIS将位置信号用地图语言显示出来，最终可通过服务中心实现车辆的定位监控、防盗反劫、服务救援、数据上报、轨迹记录等功能，并引申到其他相关服务。当前国内GPS的应用发展势头迅猛，车载GPS的监控调度管理经过多年的发展和培育，已进入规模发展时期，交通运输行业相关部门已充分意识到它在交通信息化管理方面的优势。然而，当前GPS车辆监控管理市场上当前仍是各个厂家各自为阵，各个厂家的车台终端和平台软件仍互不兼容，导致市场开拓和应用上困难重重，各个厂家为了争夺市场，不惜降低成本、质量进行价格战，同时在软件功能上也常常为争夺市场也无限制满足用户不切实际的个性化需求，甚至有些用户不惜免费提供平台软件。表现为当前的GPS系统用户容量较小、功能定制性的特征明显、功能不灵活、终端产品兼容性差等特点，总体来看这种局面不利于GPS行业的健康发展，也无法给运营商带来可观、规模化的收入。如此恶性竞争的环境情况下，非常不利于我国车辆卫星定位监控管理行业的良性健康发展。分析形成这种局面的原因，固然跟GPS监控目前自身的一些特点有关，例如，行业铺盖面广，发展时间不足没有行业统一标准等。但是也跟一些gps系统构建厂商急功近利急于推广市场，没有分析清楚用户的真正需求，没有研究摸透GPS监控系统的特点，采用的一些系统构建技术不合理、不到位有关。分析当前的许多声称成熟的GPS监控管理系统，他们仅仅是从用户应用功能角度出发，采用一些现成的技术简单集成应用，他们所做的只仅仅是：1. 构建一个和车台终端的通信服务器实现和车台终端的通信和数据转发；2. 在一台物理服务器上安装一个数据库软件，用来存储系统的GPS数据和用户数据；3. 采用现有的GIS引擎技术构建一个能展示车辆动态目标对象和车辆管理软件；4. 根据实际用户特定需求和现有一些特定厂家的车载终端协议功能被动构建系统。采用这样的简单方案，受过正规训练的IT工作者在12年内应该能彻底掌握这些开发技术，并且在半年到一年内开发出符合一些特定功能要求的系统，但是这是最初级的层次。这样简单构建的系统在系统可靠性、安全性、性能用户数量都面临较大的挑战。交通行业监管为了解决这一行业难题，同时也看到GPS定位技术在车辆交通运输行业的应用的广大发展空间，历时两年，由交通部牵头起草制定了道路运输车辆卫星定位动态监控系统标准要求，力求规范并解决这一行业难题，对行业的车辆卫星定位监控平台和车载设备终端进行规范。目前关于这一行业标准的各项标准文件已经发布，整个标准文件是经过整个业界进行了多次调研收集需求后，并且经过多次反复认证后形成的。应该说标准里面的对功能、性能、安全性的需求描述已经较为全面，且实现思路、设计流程经过业界专家的认证，标准在实现上已基本较为合理，能较好的满足交通运输行业对车辆卫星定位行业监控管理的通用要求。目前该标准作为行业标准已经强制发布实施。有别于传统的小用户量定制型GPS车辆监控管理系统，目前标准中要求的系统的功能、技术、协议更合理，对系统容量、可靠性、性能、安全性要求更高。具体包括了平台的功能技术要求、车载终端的功能技术要求、平台和车载终端间数据交换协议的标准、平台和平台间协议交换标准。这些标准的出台，很大程度上提高车辆卫星定位行业的准入门槛，同时规范了车辆卫星定位监控市场的秩序，避免了各自为战重复研发，以及恶性竞争给行业发展造成的不良影响。另一方面，对各个系统和车载终端设备研制生产厂家的研发、制造能力要求都更高，并且对于各个产业运营商的系统建设和管理服务水平也有较高的要求。本文从系统平台建设的角度出发，浅谈一下个人对交通行业标准系统平台建设的一些看法，并提出一些潜在的问题和可能的解决办法。二、 数据库的访问速度限制问题。当前的主流单机数据库系统的情况下，限于磁盘I/0的访问速度，一般每秒只有20006000之间插入存储性能。由于车辆卫星定位监控管理系统具有数据量大、数据频次高、实时性强的特点，总体对数据库的处理能力要求比较高。根据标准要求要支撑10万辆以上车辆使用，如果每辆车每隔30秒上报一条数据的话，要求系统每秒钟的处理插入速度应该要求在3千条以上，而在峰值的时候应该更多，同时还要考虑数据库的其它查询应用操作。因此，如果在普通的单机数据库环境下，常规数据库的做法必然成为车辆接入数量增加的瓶颈。而通过增加硬件性能，例如引入基于传统的以小型机/大型机作为载体的集中式数据库系统固然可以在一定程度上解决数据瓶颈的问题，但是系统构建成本较高，而且当车辆数多到一定程度时处理能力也不一定能满足应用的需求。因此，对车辆卫星定位系统平台的建设，需要考虑使用其它的数据库解决方案，这里建议采用分布式数据库系统或数据库集群等技术来解决数据存取的访问瓶颈问题。可以从几个方面共同提高发挥数据库的性能。首先，通过数据库自身的一些特性来优化使用数据库，降低数据库的对磁盘IO的访问次数。通过使用数据库记录批插入技术，使用动态交换缓存表等操作方法降低数据库的访问频次，充分发挥单机数据库的性能。对于数据库的并发查询，通过一些关键表数据预处理技术，以及对一些关键数据缓存的策略实现提高查询性能其次，通过数据库的集群镜像技术，以及通过代理软件实现读写分离，以避免读写操作不互相影响，以解决数据库访问性能瓶颈。例如，在MySql下，数据库采用成熟的MySQL-HA-Proxy、Amoeba等代理软件方案等，使读写操作分离，当然也可以自己编写数据库代理软件实现读写分离的方案。对于数据库的并发查询，通过集群的负载均衡技术的读写分离，可以一定程度上降低数据库读操作对写操作造成的影响。此种方案可以作为系统车辆数和业务数据不是非常多的情况下的一种较优解决方案，例如，在10万辆以下车载终端接入的情况下，可以较好的满足要求。再次，通过引入数据库分库设计的思想解决大数据量数据并发操作的问题。对于系统平台的车载终端接入数据量达到一定程度时，系统对某些表的操作很频繁，单纯的数据库操作达到每秒几千次写操作时，这时采用单一的数据库主机的方式很难达到性能要求，需要考虑引入数据库分库设计的方法来解决业务增长带来的数据库压力问题。分库设计是最好的解决系统数据库访问瓶颈的解决办法，但实现复杂。一种比较好的分库方法是通过按照行关键字对数据库表进行拆分或是一种分库选择，然后通过引入数据库代理层软件，在数据库代理层定义需要进行行数拆分的表和拆分规则，屏蔽拆分方式对应用程序系统的改造，使之对开发人员透明。目前业界实现了该种分库规则的代理数据库，属于开源的数据库代理中间件有PGPool-II，PGPool-II是一个工作在PostgreSQL数据库服务器和PostgreSQL数据库客户端之间的中间件。当然根据采用的数据库类型不同可以采用相应的数据库分库代理软件或者自己编写数据库代理软件实现分库规则。三、 系统平台数据通信问题。车辆卫星定位监控平台最大的特点就是数据量巨大，数据实时性强，因此数据通讯机制直接影响到整个系统的稳定性及性能。影响因素有并发通信能力、数据处理能力以及数据处理速度。以标准要求的10万辆车载终端将带来每秒将带来的是40M左右的通信流量，如果用普通的数据通信处理方式，势必造成数据在中心服务器的阻塞问题。系统建设除了要申请足够接入带宽外，还需在程序上进行业界关键技术的应用，并要优化设计，避免关键数据堵塞延时问题。首先，解决平台和车载终端间的实时通信问题处理。标准中已制定了采用TCP、UDP协议进行中心和车载终端间数据通信，每个终端在连入系统的时候就要建立起一个长连接，整个系统在满负荷情况下要同时维持十万数量级的长连接，在如此数据量的长连接下，如何在保证数据实时性的情况下有效提高单台接入服务器的客户端连接数，就成为系统设计时必须考虑的问题。目前常规的TCP通讯IO模型一般只能维持单台服务器2000个左右的客户端长连接，如果以此数目推算，系统要接入所有十万台车载终端，则需要几十台左右的通信前置机，极大的增加了系统的硬件开销。建议系统可以采用了当前TCP通讯中最高级的完成端口IO模型，该IO模型实现复杂，要成熟化稳定运行需要大量的系统实际实践才能演变出车辆卫星定位监控行业业务相匹配的架构，但是比较好的选择方案之一。其次，解决系统平台的服务器设备间的数据交换的可靠性、及时性。在大数据量协议交换的数据量情况下，如何保证系统平台的服务器设备间的数据交换的可靠性、及时性也是需要重要考虑的。系统平台服务器设备间往往存在双向的数据通讯要求，特别是车辆的位置数据定时上传，数据量大，发送频次高，在通讯峰值中，会出现短暂的链路拥堵情况，这时，客户端要下发命令到服务器就会无法即时下发或者得不到及时响应，严重影响了系统的响应时间。通过引入双通道通讯机制，特别是在用户操作终端与服务器端建立两个通讯通道，一个是数据通道，一个是指令通道，数据通道专门负责常规的GPS定位数据上传，图片数据上传等，该类数据允许在系统忙时部分丢失数据，而指令通道则专门负责对实时性要求比较高的常规指令的执行，以及系统设备间认证和链路维护指令传输作用，该通道需保证数据的及时性和可靠性。系统最终可以通过通信中间件的设计，实现满足双通道通信机制的通信中间件，作为各个中心软件设备间的通信用途要求，同时达到构件复用的目的。再次，引入数据分类优先处理规则。对于系统中一些数据通道的数据需进行优先级分类，并根据优先级别进行转发处理，例如，报警类的数据需保证其得到尽量及时，并优先得到处理。当平台系统中存在大量的车辆终端同时向GPS数据中心服务器上报数据时，可能会造成 GPS 中心服务器的数据延迟，在这种情况下，GPS 中心服务器将优先把延迟数据中的报警信息报文和命令应答报文发送到GPS监控指挥工作站，使客户能够及时处理报警信息。 最后，做好数据通信的流控机制。为了保证系统的通信和业务处理的正常进行，还需对系统的通信处理引入流控机制。在整个系统中，数据从车载终端发出，依次经过运营商系统、接口服务器、系统接入前置机、业务服务器，最后存储到数据库服务器中，监控调度工作站再从数据库获取需要的数据呈现给用户。可以看出， GPS车载终端是数据的生产者，数据库服务器是数据的消费者，而系统接入前置机和业务服务器则是中间的流通环节。GPS车载终端的数量和汇报的频率决定了数据生产的速度，而数据库服务器的数据处理能力决定了数据消费的速度。 数据流通示意图 抛开运营商的系统，要保证整个系统数据流通的稳定，需要尽量提高消费速度，即数据库服务器的处理能力，还要确保中间流通环节系统接入前置机和业务服务器的稳定畅通。在实际的设计中，系统接入前置机和业务服务器都各自拥有一个数据缓冲队列，当前一个流通环节产生阻塞时，所接收的数据都将会缓存在这个队列里面。在极端的情况下，当缓冲队列满时，为了保证数据传输的稳定性，在保证重要数据（如报警数据、车载终端应答数据等）的情况，对车载终端数据进行部分丢弃并产生系统报警。四、 引入分布式、负载均衡实现机制，保证扩展性。系统平台的车辆接入总量一般都是随着业务的开展而逐渐增长，系统架构应该满足横向与纵向的扩展的需求。在无需修改程序，不需要移动数据库数据的情况下，通过一些简单的设备安装，参数配置，实现支持系统内各设备的平稳升级，进而提高系统的车载GPS终端与操作终端工作站的接入数量，这是车辆卫星定位监控系统平台的基本要求。在实际部署系统服务器的时候，应该根据系统当前的车载终端接入量与阶段业务增长预期，采取阶段性增长的部署方案，从1万辆接入的服务器部署到5万辆的服务器部署再逐步增长到10万、20万量的部署。如果系统不支持这种灵活伸缩，就会给客户造成较大困扰。在横向扩展上，若一开始部署的服务器所支持的车辆接入量较少，则在业务增长到一定程度后，出现系统瓶颈，就会影响系统的正常使用；而一开始部署服务器所支持的车辆接入量过多的话，若业务增长预期缓慢，则会造成大量的资源浪费；在纵向扩展上，若系统架构无法满足业务的扩展需求，则无论添加多少服务器都无济于事。当系统平台内接入的客户端数目达到一定数目，各接入服务器也自然增长到相当规模，此时设备间通讯的路由就变得错综复杂，若各设备所承担的任务如果没有做很好的统筹管理，就容易出现部分设备繁忙，而部分设备空闲的现象，直接的影响就是系统内各服务器尚未有效发挥资源的情况下，就出现了运行瓶颈。为了解决以上描述的问题，同时也为了解决系统关键设备单点故障问题，可以在系统内引入负载均衡机制，主要是为了协调系统内各设备的工作，需要考虑的机制有：（1）车载GPS终端与通信前置机之间的负载均衡机制；（2）通信前置机与业务服务器之间的负载均衡机制；（3）企业工作站与接入服务器之间的负载均衡机制；（4）业务服务器与接入服务器之间的负载均衡机制。当然为了保证这么多服务器设备间的协同工作，系统还需引用一些技术辅助实现。例如，全局的缓存服务器技术、关系型内存服务器技术、一致性哈希算法策略使用等，这里就不详细介绍。五、 大批量的车载终端图标在地图上的刷新显示问题。对于GPS车辆定位管理系统需要最终展现给管理者大量车辆记号在地图上的实时位置，当车辆数多，并且车辆位置更新变化频繁时，对于系统操作终端车辆位置在地图上的刷新展示的压力非常大。一般的做法是来一个车辆位置信息就在地图上更新变化位置，这种实现方法在主流的工作站PC电脑根本处理不过来。即便通过缓存技术，定时批量更新位置信息也最多只能支撑到1000-2000个车辆记号图标在地图上刷新显示。而对于交通部行业标准要求的10万辆级别车辆的实时刷新显示问题，一般的做法更是难上加难。因此需要引入一些算法和实现手段进行特殊处理。在GIS行业中显示大量POI记号数据时，我们经常引用到通过地图聚合解决大量poi在屏幕上显示杂乱无章的问题。这里我们也可以借用GIS里常用到的地图聚合原理来实现大量动态车辆图标在地图上的刷新显示问题。只是有别于poi的聚合显示是静态的，可以根据地图的缩放级别预先处理好，而车辆卫星定位监控系统的车辆图标记号是动态变化的，需要根据车辆位置、地图缩放动态计算聚合的图元。实践证明这种方法非常有效的，同时可以解决大量车辆图标重叠杂乱无章展示的问题。六、 大量图片、视频数据的存储访问问题。车辆卫星定位监控系统的重要功能是拍照和视频采集功能。当车载终端和接入的用户终端越来越多，系统上传的图片或采集的视频文件数量将越来越多，例如：在同一时刻，1万个车载终端同时拍照向中心上传图片数据时，中心系统的对数据存取效率和存储空间是要重点考虑的问题，要不势必形成系统业务处理的一个瓶颈，同时也对系统的存储空间要求提出了挑战。传统的做法企业在存储超过1TB以上数据文件时，一般是采用DAS/NAS/SAN架构。此类架构存储几十TB以下数据还可以接受，但成本很高，比如采用NAS，一般搭一套2TB左右的系统，就需要花费100万左右，而若使用SAN架构，成本还会更高。因此对于构建车辆卫星定位监控管理系统这类的成本不能要求太高的系统，为了存储访问更大量的数据文件，需要改变原有的思想，采用新的架构，建议采用分布式文件系统解决方案。目前可以借鉴的分布式文件系统的解决方案有谷歌的GFS与Hadoop的HDFS，以及阿里巴巴的ADFS分布式文件系统解决方案，具体的这些分布式文件系统的解决方案实现原理这里不细说，可以参考相关的资料。由于车辆卫星定位监控管理系统平台需要的存储访问的文件粒度比较小，这里偏向于采用阿里巴巴ADFS分布式文件系统的存储访问的解决方案。或者基于该类文件系统的解决方案原理，可以在此基础根据车辆卫星定位监控系统的特点进行适宜性的改进以