车辆射频电子标签自动识别系统

xx股份有限公司

2008年

1.项目概述

1.1.项目背景

随着经济的不断发展，汕头市的各类机动车数量每年都在以一个相对较快的速度增长着，机动车对于道路的需求也是与日俱增。为了更好地加强对各类机动车的管理和更加有效地利用现有资源，市实施了多项重大举措，始终以科学发展观把握工作大局，突出重点，协调推进，各项工作有序开展，取得了优异的成绩。在规费征收方面的重要目标就是加强规费征收管理，着力提高征管水平。坚持“依法征收、应征不漏”的原则，切实抓好统缴工作，加大催缴力度，依法开展稽查活动，认真落实养路费计量标准，努力提高实征率。增强服务意识，创新征收手段，促使征费服务更贴心、更利民。

为了更好的实施机动车“年票制”，对非法及未缴费车辆进行有效监管，实施公路交通的规范化管理，并且对汕头市交通状况进行准确的数据分析，支持领导层的正确决策，汕头市急需部署一套自动化的车辆识别信息管理系统，该系统对经过收费站的车辆进行识别，将识别到的相关信息与后台数据库中存放的信息等进行智能比对，快速验证车辆身份及年票通行费缴交情况，根据识别结果控制车道设备进行放行或者拦截，如果遇到非法车辆和未缴交年票的情况，系统自动发出声光报警信号，提示稽查人员对该车辆依法进行处理。同时该系统还可以扩展出按次收费等的功能，使系统贯穿整个交通缴费管理的各个层面，并向其它部门提供有价值的机动车数据，以供数据挖掘和管理决策分析等使用。

1.2.项目建设目标和意义

1.2.1.项目意义

1.2.1.1.提高规费征缴水平，提高实征率

车辆射频电子标签自动识别系统以法律、法规为依据，建立机动车缴费监督体系和实时监控网络。通过部署车辆射频电子标签自动识别系统，可以督促机动车使用者自觉地进行规定费用的缴交活动。

1.2.1.2.确保车道监管的真实性、准确性

利用视频监控和数据监控技术对驶经全市20条年费车道的机动车进行全过程自动监控，对非法车辆及冲卡车辆进行自动监控记录，杜绝了人工监管的不利因素。同时系统还会监控和预防检测设备非正常工作状况，及时发现设备水平下降，监控作弊行为，保证机动车监管的真实性、公证性和准确性。

1.2.1.3.提升机动车监控数据挖掘功能

以大学路收费站控制中心为系统核心，实现全市各分站和车道之间的网络化连接，完成全市机动车辆监控信息资源共享，完善加强相关数据的收集、统计、分析等系统功能，深入挖掘信息内容，提升机动车流量等的分析及评价水平，为城市制定、法规提供科学决策依据。例如，可以根据分站工作人员对非法和冲卡车辆的处理情况给出具体的评价指标；能够实时得到各分站某时间段内通过机动车不同类别和相应数量等等。

1.2.1.4.提高管理效率和工作可靠性

通过建立全市机动车信息数据库，管理人员可以随时掌握车辆情况，完成各级各类报表生成和管理，并可以对这些数据进行在线分析，增强决策的科学性和一致性。利用自动化科技手段，最大程度提高管理效率，节省人力资源及管理成本。满足各级部门的实际需要，加强内部管理，规范服务流程，提高工作效率，提高员工素质，提升管理能力。

1.3.项目建设原则

车辆射频电子标签自动识别系统建设按照市的科学规划和明确要求，将充分体现“先进与成熟同在，高效与安全并举”的基本原则。

1.3.1.经济和技术可行性

系统在合理性价比前提下满足分步实施的要求。同时，在最大限度上既能够从整体上满足用户不断增长、变化的业务需要，又能够在保护用户投资的前提下不断利用新技术和新产品；系统采用的技术路线和采用的产品应经过实践检验，被证明是成熟可靠的，设计结果能满足客户的需求并且行之有效。

1.3.2.技术成熟性和先进性

从实际应用出发，系统尽可能采用当前最成熟和先进的技术，使技术体系架构趋于合理且适当超前，以保证今后相当一段时间内系统先进适用的状态。

1.3.3.开放性和可扩展性

采用开放的标准、技术、结构、系统组件和用户接口，保证各个分系统能够分阶段实施，并容易连接，互不影响。系统平台采用的是业界主流的基于开放标准平台技术，数据交换采用的是XML格式或行业标准报文格式。在系统设计方面，可以根据需要对系统进行必要的调整、扩充，系统设备可根据业务需求扩展数量，而整体技术方案结构无需大的更改。

在统一标准、统一管理、统一发卡的原则下，项目包含的各个系统之间保持相对性，方便将来的系统管理和业务拓展，同时也有利于系统的安全可靠性。

1.3.4.可靠性和稳定性

项目方案设计应使系统结构、设备性能、软件设计等方面具有良好的容错处理功能，主服务器及关键网络、安全设备有备份、提供容错设计，有故障检测和恢复手段等，设计结果稳定可靠，具有高MTBF（平均无故障时间）和低MTBR（平均无故障率），在技术支持和系统维护等方面具有高效的保障措施。

同时，RFID电子标签相关设备和标签的实际应用充分考虑使用环境、环境干扰、邻车道干扰、车型变化、玻璃倾角、汽车防爆膜、设备有效性、标签有效性、错卡/坏卡等不稳定因素的影响，提供具有针对性的应对措施。

1.3.5.高效性和易维护性

保证系统数据的收集、传输和使用具有快速、有效的运作效率。系统采用平台化、组件化设计，便于安装、配置、维护和使用。

1.3.6.安全性和保密性

为保障系统信息的安全准确，系统从网络平台架构、数据存储和传输手段等都具备多重保密措施。网络安全设计，采用防火墙技术和入侵检测，绝对禁止外部人员入侵；采用加密数据传输、系统分级授权管理、建立安全认证体系等多种技术措施实现系统的高度安全可靠性等。安全措施有效可信，能够在多个层次上实现安全访问控制。

电子标签防拆卸，确保车辆与电子标签的严格的一一对应关系。系统能正确区分同类的非本系统所发放的电子标签，避免非法电子标签的影响。系统在发生故障和其他原因引起的系统错误时，能迅速恢复关键数据和信息，防止出现数据丢失。相关硬件设备、标签和软件针对安全性有专门的设计和规划，并制定相关设备和天线防变更、防破坏等措施。

2.系统总体设计

2.1.系统总体建设规划

本项目采取“一次规划，分段实施”的思路分步实施，即将车辆射频电子标签自动识别系统定位于我市车辆综合管理的信息平台来规划设计，首先满足年票通行费的查验管理，同时为车辆养路规费征收、年度审验、运输管理等各种管理职能预留信息接入端口，以后视情况共享信息平台，未来将作为我市车辆管理的综合信息平台。

系统考虑与广东省公路管理局交通规费征收稽查系统连接，实现数据共享。系统建设可利用路桥管理处原有机动车辆车牌自动识别稽查系统的部分设备及软件。系统的容量满足未来5年发展的需求，支持50万辆机动车数据和100条自动稽查车道的容量。

2.2.系统设计和实现方

2.2.1.基于RUP的开发过程

车辆射频电子标签自动识别系统的建设是一项复杂的任务，需要科学的方法进行指导。为此，本系统的开发准备采用现代软件工程的成果，RUP（Rational Unified Process）软件工程方法，指导本项目的设计工作。还采用行业标准的统一建模语言(Unified Modeling Language) ，记录和描述开发工作的成果。软件过程是指实施于软件开发和维护中的阶段、方法、技术、实践及相关产物(计划、文档、模型、代码、测试用例和手册等)的集合。行之有效的软件过程可以提高开发软件组织的生产效率、提高软件质量、降低成本并减少风险。统一开发过程是一种业界领先、得到广泛验证的软件过程。

其核心是如下三点：

1.用例驱动

用例是统一开发过程用于组织业务需求的方式，通过用例模型阐述系统的业务需求，驱动一系列的开发过程，包括：创建和验证系统构架、计划迭代过程、定义测试用例和步骤、计划迭代过程、创建用户文档、组织系统的部署。

2.以架构为中心

应用系统的构架从不同的角度描述即将构建的系统，包含系统最重要的静态特征和动态特征。用例必须是可以通过适当的构架实现，构架必须支持用例。构架也必须是可进化的，以支持未来业务的发展。各种模型是可视化表示、定义、构建和文档化构架的工具，统一建模语言是定义和构建的有效工具。研究表明少量的用例(5%-10%)决定了系统的构架。统一开发过程通过迭代和增量的过程定义和细化系统构架。

3.迭代

软件生命周期示意图

统一开发方式将软件生命周期分成四个阶段，分别是：初始阶段(Inception) 、细化阶段(Elaboration) 、构造阶段(Construction) 和交付阶段(Transition) 。每个阶段的迭代有所侧重的完成一组核心流程，包括需求捕获、分析、设计、实现、测试、部署等。

考虑到统一开发过程是一种全生命周期的软件工程方法，其迭代的工作方式，可以保证本项目工作的延续性。因此决定采用该方法指导本项目的详细设计工作。

RUP过程的结构图

初始、细化、构造和交付四个阶段代表着四个大的里程碑（milestone），在每一个阶段内部都有连续的几个迭代。从图中可以看出，在细化阶段，每一次迭代（特别是最初的迭代）的主要活动是商业建模、需求分析、分析和设计，做一些简单的原型，实现和测试在此阶段所占比例不大。

首先，我们要收集系统项目的背景和需求，明确项目环境，通过对背景和需求的分析，确定项目的软件过程需要哪些工作流，这里可能会裁减掉某些RUP的标准工作流，可能会增加一些新的工作流。

下一步，确定每个工作流的工作内容和产出的工件，这时可能会比较多地对标准工作流的具体工作内容、产出的工件进行修改。

然后，确定阶段的划分，RUP将开发过程分为四个阶段（初始阶段、细化阶段、构造阶段和交付阶段），确定阶段划分主要是以风险控制为原则，根据风险的高低来决定每个阶段要执行哪几个工作流，每个工作流执行到什么程度，产出的工件有哪些，每个工件完成到什么程度。同时还要决定在每个阶段中分为几个迭代，每次迭代开发的内容有哪些。

最后，规划工作流内部结构，这是最关键的部分。工作流不是活动的简单堆积，工作流涉及到角色、活动和工件，并且工作流的复杂程度和项目规模及角色多少等有很大关系。我们根据系统的特点，根据我们以前使用RUP的经验，并和东软公司的ISO9000和CMM管理流程相结合，规定每个工作流内部的具体过程、使用的指南和模板。

模型最简单也是最本质的定义是：模型就是对现实的一种简化。由于人类在复杂问题上理解能力的局限性， 我们需要简化的模型来更好地我们要开发的系统， 将问题只局限于那些我们当时感兴趣的方面。对复杂的应用系统项目开发，项目的成功将依赖于：

●一个简化的模型帮助我们专注于我们应该注意的方面

●一个容易理解的模型帮助各方面人员的沟通和交流

●一个稳定的模型来适应未来业务的不断发展

因此，采用合适的建模方法和技巧对项目的成功是非常关键的。一个庞大复杂的系统如果没有简化的、容易理解的、稳定的业务需求模型和分析设计模型，系统很容易由于其复杂性和新颖性而进入一种不可控的状态，导致项目的失败。

要建立好的模型需要采用好的建模方法，下面将介绍适合于系统的系统建模方法，并介绍如何应用这些方法来建模的具体思路。

2.2.2.面向对象开发方法

RUP定义了软件开发的过程，而在该过程的具体实施中还需要用到具体的方法。面向对象的开发方法，特别是结合了以UML为基础的可视化建模的面向对象开发方法，由于有模型容易理解、稳定、容易过度到编码实现等优点，很适合与RUP一起来完成RUP的迭代式、组件化开发的目标。

我们采用的面向对象开发方法包括面向对象分析（OOA）、面向对象设计（OOD）、面向对象实现（OOP）三个活动。值得注意的是，在我们的面向对象开发方法中，需求建模作为面向对象分析中的重要工作而包含在其中，面向对象实现则包含编码测试和实现。它们也构成了在我们采用的RUP开发过程中的每一个迭代，都包含从OOA，OOD和OOP三个完整活动，只是在不同的迭代各有侧重。比如，在细化阶段的迭代中，OOA、OOD所占的比例较大，而在构建阶段的迭代中，则是OOP占主要地位。

下面将依次介绍每一活动的具体内容。

2.2.2.1.面向对象分析

面向对象分析包含以下任务：

●根据业务需求得到用例模型；

●开发分析原型（Analysis Prototype）；

●生成初步的对象模型上面三个任务的产出组成了业务需求模型；

●明确对象模型中类的责任和协作关系；

●创建动态模型；

●重复上述活动以得到稳定的分析对象模型。

以下分别介绍以上各个任务。

1.根据业务需求得到用例模型

用例模型是业务需求模型的重要组成部分，它包括系统所提供的功能(用例)和环境(参与者)，通过描述系统的功能与外界环境的交互关系，描述出系统的主要功能。 参与者代表系统的用户在使用系统时所扮演的一组角色，一个参与者可以是人，也可以是其它相关系统。用例则代表用来完成某个有业务意义的功能的动作序列，它描述系统做什么，但不描述如何做。

不管是人还是系统，所有和系统有交互的东西都认为是参与者；一个用例代表使用系统的一种方法，是系统对参与者所引发的事件的一系列的反映；一个用例可以有多个参与者，一个参与者通常会使用多个用例。除了用例图外，每个用例都要有用例说明，用例说明应该包括下列内容：

●名字：用例名；

●简单描述：简单地描述用例的目的和作用；

●事件流：对用例做什么的文字描述, 可以有一个基本事件流和若干可选事件流；

●非功能性需求：描述用例的非功能性需求, 比如性能；

●前置条件：定义此用例启动的先决条件, 比如参与者要先登陆等；

●后置条件：定义此用例执行完成后对系统的约束要求；

●扩展点：描述在用例的执行流程中的一些地点, 在哪里可能执行扩展(extend)该用例的与该点名称相应的用例中过程。

在面向对象开发中，用例模型的使用将跨越从需求建模、分析、设计到实现测试的整个阶段，可以被用来：

●定义应用系统的边界；

●描述系统如何与外界交互；

●作为获得其它分析设计模型的基础；

●作为创建测试用例的基础；

●作为变更控制的基础。

一个完整的用例模型必须确认所有的参与者以及主要用例都被发现、描述，并包括到模型中去了。

2.开发分析原型

除用例模型外，业务需求模型的另一主要内容是分析原型，它由关键用户界面组成，用于演示系统实际外观界面和界面间的迁移。

3.得到初步对象模型

业务需求模型的另一个主要内容是业务对象模型，它描述了：

●组成应用系统的关键对象类；

●类之间的关系；

●类的属性；

●类提供的方法。

在业务需求建模阶段，通过和用户一起寻找关键业务对象类和类之间的关系，最后提交一个初步的对象模型。该模型只包括关键业务对象类、类的属性和类之间的关系，基本没有类的行为的详细定义。对象模型还有一个很重要的内容就是建立一个完整的模型字典，其中精确地描述每个类在业务范围中的定义的属性、方法和使用、用途等信息。

有了用例模型、用户界面和初步的对象模型后，我们就得到了一个基本完整的业务需求模型。除此之外，还可根据实际需要给业务需求模型加入下列内容：

●活动图：用来捕获系统内部工作流的各种活动,活动间控制关系, 活动的参与者以及活动间对象传递的流程图；

●业务规则：用来描述用例中有关业务规则。

4.确认类的责任和协作关系

面向对象分析（OOA）的主要任务是理解业务需求, 构建一个针对业务需求和功能所对应的、与实现模型和具体实施技术平台无关的软件逻辑模型。

在面向对象的开发中，该软件逻辑模型包括静态模型和动态模型两个部分。前面几个活动中我们已经分析了静态模型，后面则要分析动态模型。

在创建顺序图等动态模型之前需要先确定类的责任和类在用例场景中的相互作用关系。这时可以利用CRC之类的方法，通过分析业务需求、用例模型或角色扮演，得到在各场景中每个类的责任和与其他类之间的协作关系。

5.创建动态模型

为了进一步明确需求，这时需要对对象之间的相互关系和对象内部的状态变化做进一步的细化，这就是创建业务的动态模型。动态模型包括顺序图/协作图（反映对象间关系）和状态图（反映对象内部状态的变化）。动态模型也是根据用例模型得到的，主要是通过分析用例的事件流。

6.重复上述活动以得到稳定的分析对象模型

上述过程可能需要反复多次以得到稳定的分析对象模型。

2.2.2.2.面向对象设计

面向对象设计的主要工作是细化面向对象分析所得到的模型。面向对象分析主要考虑满足需求, 面向对象设计则重点考虑实现方案。软件的体系结构，各种需要实现的具体算法，以及底层服务（比如持久化, 分布, 并行, 安全等等）的使用, 需要在设计中细化出它们的实现。面向对象设计主要包括下列三个任务：

●系统设计

●对象设计

●对象持久化设计

下面分别介绍它们。

1.系统设计

系统设计包含三个方面的内容：

●将分析活动得到的对象组织成若干子系统；

●选择合适的技术和系统结构模式来构建应用的体系结构；

●将各子系统分配到体系结构中去；

其中，系统结构模式的定义为：用于描述软件系统的基本结构框架。 它包含一组预定义的子系统，并定义了这些子系统的作用, 相互间关系以及所含的规则。有下列这些常见的系统结构模式：

●层次模式：在层次模式中, 应用被分解为若干层次。 现在流行的应用系统三层架构, 网络服务的七层协议都是典型的层次模式的例子；

●MVC模式：即模型-视图-控制(Model-View-Controller)模式。 在MVC模式中, 应用分为三部分：模型负责数据和其中的规则, 视图负责信息如何展现给用户，控制则负责处理用户的输入。

值得注意的是, 系统结构模式是可以协同工作的。比如，当前流行的应用系统中都同时采用了三层结构的层次模式和显示与业务分离的MVC模式。所有的系统结构模式都有自己的优点和缺点。

在应用系统中，最重要的系统结构模式就是层次模式。分层意味着按一定顺序来组织系统功能，业务相关的功能放在上面的层次，公共的功能放在中间层， 而和具体部署平台紧密关联的功能则放在下面的层次。分层的数量和每一层的粒度决定于所要解决问题的复杂度。

一般说来，大型系统都需要分层。

分层的一般原则为：

●将系统的组件组织起来, 并按照从上到下的顺序排放；

●保证上层组件只能使用它以下层次的组件，下层组件不能使用上层的组件；

●不要跨层使用，即只使用刚好在下面一层的组件。

除了系统结构模式，应用系统结构还包括确定业务需求模型中的技术平台，比如各种中间件产品。 

除了应用系统结构外，系统设计还要考虑硬件系统的体系结构，包括网络的拓扑结构等，并要确定如何将业务子系统和其它软件平台分配到具体的硬件上去。

2.对象设计

对象设计将进一步细化对象分析产生的对象模型。前面阐述了，分析模型是完全与需求相对应的。当在设计活动中考虑它们的具体实现时，需要将分析模型中的面向业务的类映射到多个面向实现的类。主要有这样三种面向实现的类：

●界面类：提供用户界面的实现；

●应用类：为了重用及性能等原因而对分析模型中的类重新组织过的类；

●服务类：实现一些公共基本服务的类，比如各种数据结构类，提供底层技术平台服务的类。

3.对象持久化设计

对象持久化设计的三个任务：

●设计关系数据库结构；

●设计对象模型到关系数据库的映射；

●设计数据库的访问接口。

在大部分应用系统中，数据都是存在关系数据库中的。由于面向对象方法中的类和关系数据库中的数据存在没有简单的映射关系，虽然现在有许多的中间件产品可以帮助我们方便地实现O-R(对象－关系)转换，比如TopLink、EJB等，但数据库结构和对象模型的差异（Impedance Mismatch）还是有可能在性能及开发效率上造成麻烦。因此，即使在面向对象开发的方法中，也必须在精心设计数据库的结构或O-R间的映射关系，或重新改变应用类的结构。

对象持久化的另一个任务是通过改变应用类，或引入一些服务类来实现O-R转换及原子操作（Unit of Work）。

2.2.2.3.面向对象实现

这一阶段的工作主要是基于面向对象设计活动所得到的模型，使用面向对象程序语言，实现一个完全满足模型要求的可执行的系统。在实现阶段要注意将经过测试的可重用的组件管理起来，在以后的迭代中使用。

2.2.3.车辆射频电子标签自动识别系统建模方法

2.2.3.1.业务需求分析方法

首先，业务需求建模人员通过以下三种途径来获取系统业务的现实需求。

1.与相关人员的交流

由于相关人员中基本上都是不懂（精通）技术的业务人员，因此和他们的交流不能通过技术性太强的媒介，而应尽量采用大家都能理解的方式，比如谈话。为了减少通常交谈和普通文字表述中太多的二义性，需要采用一些比较严格的可视化的表述手段，比如功能分解图，业务流程图等。除了交流媒介的选择之外，还要注意的就是相关人员的选择要有广泛性和代表性。系统是一个非常复杂的系统，很难找到一个人能完全将它描述清楚。每个人都只能从自己的一个角度出发来描述该系统的一个或几个方面。要得到整个系统的全面的模型，必须要从尽量多的角度来了解此系统。影响相关人员对系统的认识角度不同有以下方面：

●职位：汕头市路桥收费管理处领导，各收费站负责人和车道工作人员及设备厂商人员对系统的理解和看法是不一样，模型必须要能反映出这些区别。将从上到下的观点综合统一， 形成的模型就是业务系统的基础。

●岗位分工：不同岗位的人，他们对系统的观点也不相同。准确分析他们的各自观点和需求，然后将它们综合起来，将为业务系统的建设打下坚实的基础。

2.运行现有的业务系统

通过直接运行汕头市路桥收费管理处方面原有的机动车辆车牌自动识别稽查系统，可以获得第一手资料，有助于更准确地把握业务需求。此外，还能了解用户的使用习惯和希望改进的地方，作为后续分析与设计的指导。

3.利用相关资料

通过分析其它一些相关资料， 我们可以比较快地对汕头市路桥收费业务有个整体性的把握，加速我们的进度。

然后，业务需求建模人员通过分析归纳，整理和抽象出业务需求模型，它包括用例模型、用户界面、初步的业务对象模型、活动图等。业务需求模型是对现有业务规划结果的一个抽象，有助于我们理解系统业务，并清楚其中不规范，不确定和不明确的地方，使我们能有针对性地提出对这几个高风险因素的应对策略。总之，业务需求模型是后续开发的出发点和基础。

在得到业务需求模型后，还有一个很重要的步骤就是和相关人员一起来确认该模型。如果不能达成一致则需要重复上面的一些过程，直到双方都认同该模型为止。

在业务需求建模的过程中，除了获得业务需求模型外，还要注意对业务需求未来变化和发展趋势的收集与整理。把握需求的变化趋势，对后续的设计开发有着非常重要的积极意义。在上述过程框架中，有下面几种了解业务需求未来发展和变化趋势的途径：

2.2.3.2.系统分析设计方法

在系统的分析设计建模中，面临的最大挑战是：

如何为不规范，不确定甚至不明确的业务需求建立一个稳定的软件逻辑模型？我们总希望在业务需求模型中尽量地减少业务的不规范，不确定和不明确。但是，由于以下客观原因，使得要完全消除它们是不可能的：

汕头市车辆射频电子标签自动识别系统在国内目前来说是一个比较崭新的模式，而且涉及到很多技术上、业务上的创新，因此必然有些模型目前是不确定的，也有一些是大家都还不明确的。既然这些不规范，不确定和不明确是客观存在的，我们就必须保证我们建立的模型有足够的弹性来包容它们，不致因为它们而造成模型的频繁改动， 进而导致后续工作成果甚至最终应用系统的频繁改动，最后使得系统因不可维护而崩溃。

在分析建模阶段，我们可以通过一些灵活的设计方法来建立比较有弹性的模型， 它们能在一定范围内包容业务的不规范，不确定和不明确。

3.中心系统设计

3.1.总体功能

总控制中心系统负责系统参数的设置、数据接收、数据存储、数据汇总、参数的更新与下发等，主要功能包括：

（一）控制中心管理模块：实现整个系统的参数设置，对车辆进行信息管理，处理稽查纪录和异常情况，并对数据进行汇总、查询、统计和维护。

（二）电子标签发行模块：实现电子标签的发行、换卡、销卡以及维护，电子标签的信息登记、复核，电子标签信息查询统计以及数据备份与恢复。

（三）监控模块：监控各个稽查站和车道的过车情况和运行状态，处理异常情况和报警信息以及对过车情况进行记录、统计和查询。

（四）接口模块：实现与交警系统、各交通管理部门的管理系统、车牌自动识别系统、分站管理中心以及网络传输接口。

3.2.RFID识别系统管理软件

系统参数的设置，包括人员权限、稽查站点信息、车型、系统基准时间及车载卡启用日期等/接收并管理车辆年票缴交信息（目前由公路局提供相关数据）/维护车载卡黑名单/接收/处理各稽查站的稽查记录、异常车辆数据及图片信息/至少每天一次定期向各稽查站下发运营参数,包括年票缴交情况、黑名单等/存储/汇总各稽查站点所有相关稽查记录/提供手工（通过移动介质）导入稽查记录及手工下发运营参数的功能/查询车辆信息数据、稽查记录数据、车载卡发行数据、系统设置数据等/监控各稽查站客户端的联接状态,以便及时进行维护/各类数据的备份与恢复

3.3.标签管理

车辆信息登记与复核管理、年票征收管理、电子标签的管理、电子标签发行,包括:发放、换卡、销卡和维护维修管理、免费电子标签发行、复核管理、发送车辆费用缴交、催缴或其它各类提示短信、查询打印各类报表、车辆、车载卡发行信息查询、统计/系统数据的备份与恢复/实现用户需求的其它功能。

3.4.报表管理软件

查询/统计/打印中心数据库相关报表/实现用户需求的功能

3.5.系统服务网站

建立车辆射频电子标签自动识别系统对外一个公众形象门户网站，通过网站群众可以查询一些年票的缴交信息、管理网站职能单位介绍、网站信息查询模块、信息发布模块、用户登录管理权限模块、实现用户需求等功能。

4.车道稽查

车道稽查系统能够自动识别电子标签，与存储在车道上的年票缴交情况表进行智能比对，快速验证车辆身份及年票缴交情况，车道系统的功能包括：

（1）在车辆进入到车道时，自动对进入该车道的车辆进行图像抓拍，自动识别车牌号码和电子标签ID号；

（2）将识别出来的车牌号码和电子标签ID号与年票数据库中记录的数据进行比对，并显示稽查结果；

（3）可实时接收站级分系统下发的年票数据，并据此进行年票稽查；

（4）上传欠费车名单、冲卡车名单等数据至各分站数据库。

5.电子标签发行站

5.1.发行站功能

1．建立车辆与车卡的一一对应关系，包括车卡ID号、车卡明码号。

2．做好车卡的信息初始化工作。

3．车卡的选择包括任意匹配与明码号自选。

4．建立基站本地数据库，存放发卡及验卡车辆信息，每天将发卡及验卡处理完毕的信息移到历史记录表中。

5．提供操作员登录验证管理，记录上岗人员的工作时间。

6．提供本地数据库维护工具（功能菜单），只能由发卡组长使用。

7．提供一个人机输入界面，定义车卡存储规划、操作人员及进行数据表格维护。

5.2.发卡基站工作流程

图5  发卡基站主流程

图6  发卡处理线程流程图下载本文