交通信号控制系统与公安交通 集成指挥平台通信协议研究.doc

交通信号控制系统与公安交通 集成指挥平台通信协议研究1.引言交通信号控制系统是缓解城市交通拥挤、保障城市交通安全、有序、畅通的一种重要的交通解决方案。由于我国在道路交通信号控制系统的应用和研究工作方面相对国外发达国家来说起步较晚，因此系统建设走的是引进与自主研发并行的道路，经过20世纪80年代至今这几十年的发展和建设，国内交通信号控制系统建设取得了快速发展，形成了众多的的交通信号控制系统应用品牌。但是，作为交通信号控制系统建设非常重要一环的通信标准、通信协议的制定工作却较为落后，现有系统大都基于各厂家私有协议，缺乏统一接口标准，直接导致了信号控制系统的信息难以为其他交通管理业务系统服务，大大降低了系统的应用效率。随着我国经济的飞速发展，为适应不断增长的交通管理需求，各种交通管理应用系统逐步建成。如何综合这些系统中种类繁多的交通信息，对其功能进行集成应用，从而及时全面地掌控复杂交通状况，实时监控和调度各类交通资源成为急需解决的问题。公安交通集成指挥平台由此而诞生，它集成了公安交通管理中各业务系统的主要功能和信息，实现交通研判数据化和交通指挥精确化，使得交通管理部门决策科学、指挥灵敏、反应及时、响应快速，大大提高了指挥调度效率。而城市道路交通信号控制系统是城市交通管理中重要的组成部分，公安交通集成指挥平台如何集成目前种类繁多的交通信号控制系统，实现数据的双向交换成为急需解决的问题。本文针对我国目前交通信号控制系统和公安交通集成指挥平台普遍建设中数据通信协议标准缺失的问题，通过分析国内外现有道路交通信号系统的应用及相关通信协议现状，归纳整理了公安交通集成指挥平台对交通信号控制系统的功能及数据需求，提出了基于信息层交换的轻量级构架，设计了基于XML组织数据内容的通信协议，为实现公安交通集成指挥平台对交通信号控制系统的集成提供了一种较为通用的方法。2.国内外现2.1.国内信号系统及交通集成指挥平台应用情况我国在城市交通信号控制系统的研究和应用工作方面起步较晚，20世纪80年代以来,一方面进行了以改善城市市中心交通为核心的UTSM（城市交通信号管理）技术研究；另一方面采取引进与开发相结合的方针，引入了部分国外的道路交通控制系统（如上海、杭州的SCATS系统，北京、成都的SCOOT系统，武汉、长春的ITACA系统等）。其后、随着国内交通信号控制技术的逐步成熟，一批针对我国交通流特点、具有自主知识产权的交通信号控制系统（如华通HT-UTCS，海信HiCon等等）相继出现。经过这几十年的发展和建设，我国城市交通信号控制系统的市场品牌总数达到20多个，据不完全统计，截至2007年底，全国信号灯控制的路口数量达到四万二千个，在道路上运行的信号机达到了四万二千多台。2000年全国交警部门开始建设公安交通集成指挥平台，目前，全国共有590余个城市（包括县级市）建成了集警情采集、交通流信息采集、交通控制等功能于一体的交通集成指挥平台，其中400余个城市实现了信号区域控制或主次干道“绿波带”（线协调控制）控制。2.2.国内外信号控制系统的通信协议、标准现状在国外，城市交通信号控制系统技术已较为成熟，但也出现了系统与设备、系统与系统之间的互联、互操作的难题。于是，美国国家电器制造商协会NEMA（NationalElectricalManufacturersAssociation）于1992年着手开发通用性的交通信号控制系统通信协议（NTCIP：NationalTransportationCommunicationsforITSProtocol）。其初步设计构想源自于交通信号机的应用需求：无论任何一种交通信号控制系统以及信号机只要遵从NTCIP协议就可以实现互联、互操作和实时通信。目前，由ITE、AASHTO与NEMA共同组成的NTCIP联合委员会已通过报告、期刊与网站等方式进行NTCIP技术与应用的推广。现阶段，NTCIP已上升为针对智能交通系统电子设备间数据传输所制定的标准通信协议。其主要目标是确保交通控制与ITS系统组成单元彼此之间的“互操作性（Interoperability）”与“互换性（Interchangeability）”。NTCIP的应用一般分为两大类：中心到外场（C2F）及中心到中心（C2C）的应用。前者通常包含路侧设施或者是各运营部门所拥有的车辆与管理中心的计算机之间的信息传输。而后者则主要是管理中心的计算机或各个子系统之间的数据传输。NTCIP标准采用了分层的架构，分别为信息层，应用层，传输层，子网络层和物理层。其架构如图1所示        可以看出，NTCIP是遵照OSI参考模型的规范，类似ISO的OSI七层协议模型，提供交通控制中心与现场设备或与不同控制中心之间通信的标准。对于应用层、传输层、子网络层、实体层都应用了已有的成熟标准，其关键是制定了信息层的相关标准。而与交通信号控制系统中相关的NTCIP标准有：NTCIP1201、1202等，与中心到中心通信相关的NTCIP标准有：NTCIP2500、2501、2502等。国内交通信号控制系统通信协议、标准现状1993年公安部制订了我国信号机的行业标准GA/T47-93交通信号机技术要求与测试方法，该标准按基本功能对交通信号机作了分类，规定了交通信号机的技术要求和测试方法，是我国首个信号机标准。2002年公安部对该标准进行了修订，并改为强制性标准GA47-2002道路交通信号控制机。新标准对集中协调式道路交通信号机的物理通信接口、基本通信内容进行了规定，但具体通信协议、格式等内容未包含在标准中。2004年，公安部颁布了行业标准GA/T509城市交通信号控制系统术语规定了城市交通信号控制系统中的专用术语。2005年，颁布了GA/T527城市道路交通信号控制方式适用规范规定了城市道路交通信号控制方式。以上标准都未涉及通信协议方面的内容。            2008年我国正式出台国家标准GB/T20999-2007交通信号控制机与上位机间的数据通信协议，该标准规定了信号机与上位机间的数据通信协议的结构及物理层、数据链路层、网络层和应用层的要求，协议在参考美国NTCIP协议和美国加州AB3418标准的基础上，采用了四层结构，见图2。适用于交通信号控制系统信号机与上位机间的通信，此项标准的发布，对我国信号控制系统来说无疑是一大进步。2010年颁布了道路交通信号控制机与车辆检测器间的通信协议规定了道路交通信号控制机与车辆检测器间的串行接口和以太网接口的数据交换规程。 2.3.        国内外信号系统及协议比较分析         以下选择了当前在我国使用的最具代表性及实效性的国外系统和部分我国自主研发的交通信号控制系统进行系统的分析和比较。如表格 1所示：系统名称研制单位特征内部协议数据交换协议结构SCOOT英国交通与道路研究所方案形成式自适应控制系统私有协议无集中式控制SCATS澳大利亚新南威尔士州道路交通局方案选择式自适应控制系统私有协议自定义ITS接口协议三级分布式控制ACTRA美国西门子公司方案形成式专家系统的自适应控制系统NTCIP协议自定义接口协议分布式控制HT-UTCS公安部交通管理科学研究所方案形成专家系统式自适应控制系统私有协议自定义接口协议三级分布式控制海信HiCon青岛海信网络科技股份有限公司感应式协调、方案选择NTCIP自定义接口协议三级分布式控制莱思信号系统南京莱斯信息技术有限公司自适应控制私有协议自定义接口协议二级分布式 表格 1国内外城市道路交通信号控制系统分析表        以上系统都有各自的特点，但在系统内、外部数据交换协议方面类似，大都采用私有协议及自定义接口。在系统内部数据交换方面：国外系统中心与信号机都按照系统各自专用的协议进行数据的传输，只能使用自己的专用信号机，对国产信号机都无兼容性；国内系统同样如此，系统与系统，系统与信号机之间相互不兼容。当前，我国信号机与上位之间通信协议的国家标准GB20999虽然已经制定并颁布，但其正式应用尚未展开，从目前情况来看，国外系统使用GB20999的可能性极小，国内系统使用该标准的也极少，包括这个标准的制定单位青岛海信网络科技股份有限公司自身的信号控制系统尚未应用该标准，而是使用了NTCIP。在系统外部数据交换方面：各个系统大多提供了与外部系统数据交换的接口，但是目前接口协议都是用各自专用的协议来进行数据交换。       综上所述，对于城市交通信号控制系统通信协议标准，国外研究比较早，已形成了NTCIP协议标准，而国内由于在ITS系统建设及其相关技术研究方面起步较晚，目前通信协议相关标准仍在制定过程中。在交通信号控制系统通信协议标准方面，目前仅有GBT20999交通信号机与上位机通信信协议与GAT920-2010信号机与检测器间的通信协议这2个标准，标准层次较低，在应用层消息定义中仍关注的是以参数帧代码为基础的机器会话方式，与应用程序的联系较差，没有体现应用层定义的优势。交通信号控制系统系统与其他ITS系统之间系统层面的通信标准、通信协议尚未制定，现有的各系统都使用厂家私有的通信协议。随着公安交通管理信息技术的深化应用和发展，对各类交通信息的采集分析、集成应用的要求越来越高，交通信号控制系统作为公安集成指挥平台重要的子系统，在城市交通管理现代化建设中倍受关注，如何与交通信号控制系统进行数据交换成为急需解决的问题。3.     需求分析3.1.   应用范围与定位            通信协议用于交通信号控制系统与公安交通集成指挥平台之间的数据交换，是一个中心对中心（C2C）的通信协议。           通信协议的功能定位于公安交通集成指挥平台对交通信号控制系统信息的集中、共享、显示、监管这4各方面。1）  集中：指对所有现场交通信号机及交通信号控制系统的各项信息集中管理；                 2）  共享：外部系统可以获取交通信号控制系统数据，交通信号控制系统也可以获取外部系统的数据，实现数据双向交换；                3）  显示：可以不通过交通信号控制系统的功能界面直接在指挥平台中显示信号控制系统和现场信号机的动、静态数据；                4） 管：包括2个方面，一是对整个交通信号控制系统及其控制的现场交通信号机的实时状态、故障、运行效果的监测；二是对系统及其控制的现场信号机的日志及采集的交通流数据进行查询统计，用于后期的评价、评估及故障、状态回溯。通过公安集成指挥平台对交通信号控制系统数据交换内容和格式的总结分析，得出数据交换的基本需求：n      通用、开放、可扩展的数据格式标准；n      数据交换内容是结构化和层次化的；n      能实现中心（公安交通集成指挥平台）与不同厂商信号系统的可靠通信和交互控制，解决对不同信号系统的兼容性。3.2.   功能需求通过调研与项目实施经验的总结，总结并整理出接入公安集成指挥平台的交通信号控制系统必须具备的功能要求：1)    能够与所有系统控制路口信号机进行实时通信；2)    具备中央、区域、路口三级控制功能，系统内所有路口划分区域进行管理；3)    具备实时控制接口，能够对路口信号机进行简单的实时控制。支持单点多时段定时控制方式、单点感应控制方式、上位机控制、线协调控制方式、区域协调控制方式等控制方式；4)    具备道路交叉口的交通流信息采集与记录功能；5)    具备路口信号机的故障检测及自动报警功能；6)    具备系统数据输出接口，能够提供所需各类数据；7)    具备交通流数据输入接口。3.3.   数据需求基于以上功能要求，整理了两大类数据需求。1）  系统配置数据系统信息：包括系统名称，版本号，供应商，系统包含的区域号列表；区域配置信息：包括区域的编号，名称，每个区域的子区号列表，路口号列表；子区配置信息：子区的编号，名称，子区中包含的路口号列表。可以不设子区；路口配置信息：路口的编号，名称，特征，检测器、车道、相位、阶段配时及配时方案等信息。2）  系统运行数据运行状态数据：包括系统时间、系统运行状态、各区域、各路口运行状态等数据；故障报警数据：路口通信断开，信号机、信号灯、检测器等故障报警；路口的实时控制数据：包括当前配时方案号，控制方式，周期，阶段相位等；路口交通流数据：包括流量、占有率、平均车速。3.4.   其他需求1）  可靠性能够满足交通信号控制系统与公安交通集成指挥平台之间不间断的稳定数据交换通信需要。2）  安全性、完整性交通信号控制系统必须保证高度的运行安全性来确保交通的安全、可靠和畅通。因此，通信协议的设计，遵循不将传输信息和指令与某种固定的传输模式进行捆绑的原则。即协议的数据不局限于某种特定的传输方式，同时支持安全认证和授权机制、数据的完整性、安全性等。3）  时效性控制消息、状态变换消息以及交通流数据的通信低延时要求。4）  可扩展性建立在开放、通用的标准之上，能够适应需求的变化，在不影响现有应用的前提下，灵活的扩展通信信息内容。4.     通信协议结构及内容实现4.1.   设计原则及目标通过需求分析，依据交通信号控制系统数据交换的内容和特点，充分考虑可扩展性和可实施性，制定的设计原则如下：n      遵守现有的相关标准交通信号控制系统涉及交通、计算机、通信等众多的领域，数据交换通信协议必须与相关的标准相兼容和协调。协议交换的数据应遵循交通信号控制机及通信现有国家标准与行业标准。n      开放性建立在开放、通用的标准之上。兼容国内外交通信号控制系统，支持中英文。n      可实施性数据交换的格式决定系统运行的效率以及对通信的依赖程度，要满足系统的“交互性”，数据的格式应当是一种能够容易上升为标准的格式，也能被系统开发者便于接受和广泛使用的格式。协议应立足交通信号控制系统的客观需求，着眼于我国交通信号控制系统的发展趋势，以标准化系统的应用开发以及统一化数据交换格式为目标。就目前来说，该数据交换通信协议力求建立一个符合我国城市交通信号控制系统中心与公安交通集成指挥平台数据交换要求的基本规范。它能够提供一套统一、灵活、开放和可扩充的交通信号控制系统数据交换规范语言，并充分考虑了城市交通信号控制系统与公安交通集成指挥平台的接口及接入方式的可行性及实施代价。4.2.   协议结构1）  OSI模型OSI模型是一个由国际标准化组织（ISO）提出的开放系统互连参考模型，有7层结构，每层都可以有几个子层。OSI的7层从上到下分别是：7应用层->6表示层->5会话层->4传输层->3网络层->2数据链路层->1物理层。其中高层，既7、6、5、4层定义了应用程序的功能，下面3层，既3、2、1层主要面向通过网络的端到端的数据流。OSI模型通过七个层次化的结构模型使不同的系统不同的网络之间实现可靠的通讯，最主要的功能使就是帮助不同类型的主机实现数据传输。2）  NTCIP使用的5层模型结构OSI 7层模型是现有计算机网络应用的基础，目前广泛应用的各类计算机通信协议都是基于它设计建立的，例如著名的Internet通讯基础协议TCP/IP。现有交通控制自动化技术都是以计算机信息技术为基础建立起来的，因此交通控制相关通信协议的设计都参考和借鉴了计算机通信的协议、规范。NTCIP协议的设计同样参考了OSI分层模型，但是简化为了5层。通常，两个计算机或其他的电子设备之间的数据通信能够包括以下的主要层：叫做NTCIP“层”，用来和OSI模型定义的层相区分。 NTCIP信息层信息标准定义了数据和信息的意义，并且通常涉及ITS信息（不同于通信网络信息）。NTCIP应用层应用标准定义了数据交换信息的规则和程序。NTCIP传输层传输标准定义了交换网络上两点之间的应用数据的规则和程序，包括任何必要的路经、信息拆分/重组和网络管理功能。NTCIP子网络层子网络标准定义了某些通信媒体上两个“相临”设备间的数据交换的规则和程序。NTCIP实体层实体层包括使用NTCIP通信标准并将对用于挑选出的通信基础设施上适当的子网络层的选择有直接影响的通信设施。3）  本通信协议的结构设计本协议结构的设计在借鉴上述模型的同时也考虑了目前国内的实际情况。我国交通信号控制机以及其控制系统主要由企业设计制造，目前市场上已有国内外的多家信号机生产厂商开发的信号控制系统实际应用，在目前先有系统后设计通信协议的实际情况下要充分考虑现有系统的实际应用情况，各个信号系统厂商的接受程度以及实施代价，这也是通信协议能否被顺利采纳的重要因素。从目前已有交通信号控制系统接口来看，主要包含以下几类：基于Socket的字节数据封装接口、基于XML的消息通讯接口、基于CORBA的接口、以及基于Socket的自定义消息接口。这4大类接口在NTCIP的各层（参见图 1）中的实现都具备多条选择路径，每一层都基于现有的通信协议可选择多种实现，各厂商根据自身的技术储备及应用要求在从应用层到实体层的实现各不相同。当前如果在设计通信协议中对每一层的具体实现技术、协议再做出唯一的规定显然不切合实际情况，也不可能为广大信号系统厂商接受。因此，基于“信息层”来定义确定交通信号控制系统与集成指挥平台交换数据的范围，定义数据和信息的意义，对于应用层、传输层、子网络层及实体层不做强制要求，由各个厂商选择最适合应用场景的技术来实现，是符合当前实际情况的最佳选择。参考NTCIP协议的分层结构，结合交通信号控制系统与公安交通集成指挥系统的具体通信需求，以及目前我国市场上使用的各种国内外交通信号控制系统的实际情况，设计了基于“信息层”的数据交换通信协议，见图6。 4.3.   基于XML的协议内容组织XML作为一种元标记语言，它提供了一个标准，利用这个标准，应用系统可以根据需要制定自身领域的新标记语言和配套标签。XML这一能够以统一的格式描述信息的文本化语言，将不同系统来源的信息按照统一的格式描述和相互转换，已经成为了信息标准化进程和数据交换的有力工具。XML最突出的应用就在于作为信息交换的数据格式技术标准，它本身具有自描述性、可扩展性、可移植性和结构性的特点，所以基于XML的数据描述格式的扩展性和灵活性允许它描述不同种类应用软件中的数据。XML不依赖于平台、厂商和特定应用程序的特性，因此可以被应用于异构平台和不同应用程序间的数据交换和集成，允许异构数据系统之间交换数据的一种办法是为所有的输入输出系统分别制定统一的数据交换格式。XML能根据特定的应用定义自己的标签来描述数据是其最重要的功能，而且XML的最终目标是提供异构与系统、厂商无关的统一解决方案。交通信号控制系统中存在中心到中心数据交换和共享的需求，通过分析发现，由于现有系统是由不同的软件开发商采用各自喜好的数据格式来开发实施，存在数据格式的差异性，导致了系统集成和系统之间数据交换的难度、甚至不能进行数据交换。要使交通信号系统能被有效的集成到智能交通系统体系中，大家已经公认只有通过采用统一、标准化的数据格式或采用达成一致的中间件才能的得到有效的解决。XML正是能满足这些需求的一种开放的、通用的数据描述标准，在定义数据结构的同时可以突出对结构的描述，从而体现出数据之间的关系。而且，基于XML的数据格式标准不依赖于操作系统、编程模式或编程语言，以及目前大量XML开发工具在各种软硬件平台上都具备丰富应用的实际情况，为交通信号控制系统的集成提供了一种简单、性价比好的解决方案。4.4.   通信封包通信双方设计以互发数据包的模式来实现数据交换。数据包也称为消息以XML序言加上根元素标记开头，UTCSPkg>标记结尾的一组字符串数据。采用XML语言封装，XML版本1.0，使用GB18030字符集，UTF-8编码。参考GB-20999标准中消息类型的定义，我们设计了类似的消息类型以及对应消息类型的处理流程，通过如下图 7的通信包结构来封装所有通讯数据。 具体定义如下：UTF-8"?>    版本号Ver>令牌    源地址Src>    目的地址Dest>    消息类型序列号Seq>           ”顺序编号” name=”操作说明”>                              UTCSPkg>n        版本号:Ver>标记之间的内容为消息的版本号。n        令牌:标记之间的内容为消息的令牌，用于验证数据通信双方的会话是否经过认证。n        源地址:Src>标记之间的内容为消息的源地址，它表示了消息的发送方（交通信号控制系统或公安交通集成指挥平台）。n        目的地址:Dest>标记之间的内容为消息的目的地址，它表示了消息的接收方。n        消息类型:标记之间的内容为消息的类型，分为以下4种类型:请求消息（Req），应答消息（Resp），主动推出消息（Push），错误消息（Err）。n        序列号:Seq>标记之间的内容为消息的序列号，用于应答消息和发送消息之间的一一或者多对一的对应。n        消息体:标记之间的内容为消息体，它包含了消息的具体内容。消息体中可以包含一个或多个操作命令。n        操作命令:标记之间的内容为操作命令，它包含了消息的具体内容。操作命令包含了两个属性:No表示操作命令的顺序编号，从1开始。name表示操作命令的说明。单个操作命令可以包含一个或多个操作对象。n        操作对象: 标记之间的内容为操作对象，包含对象的具体属性信息子元素。这里的Object是代指，其具体的元素id标识了对象的具体类型，其取值参见4.5。4.5.   通信协议数据通信协议数据即通信封包中操作对象Object的具体定义。根据前期确定的数据需求，可以把数据根据数据类型分为以下几个大类。1）系统数据字典2）信号系统配置数据，其组织结构如下图所示： 注：可以不设子区，路口与子区并列直属区域4）  系统运行数据 5）  系统控制数据协议中每一个对象的具体内容不在此详细列出，仅以路口参数对象CrossParam为例：       RegionNo>CrossNo>CrossName>       DetNo>DetNoList>       LaneNo>LaneNoList>              取值说明见下表格 2序号元素名说明1RegionNo区域号（从1开始）2CrossNo路口号（从1开始）3CrossName名称4Feature特征5DetNoList检测器号列表6DetNo检测器号（从1开始，在单个路口中唯一）7LaneNoList车道号列表8LaneNo车道号（从1开始，在单个路口中唯一）9PhaseNoList相位号列表10PhaseNo相位号（从1开始，在单个路口中唯一）11StageNoList阶段号列表12StageNo阶段号（从1开始，在单个路口中唯一）13PlanNoList配时方案号列表14PlanNo配时方案号（从1开始，在单个路口中唯一） 表格 2路口参数对象取值说明5.交通信号控制系统数据交换接口软件1.      软件简介交通信号控制系统数据交换接口软件基于上述通信协议开发，使用计算机网络通讯技术，实现了交通信号控制系统和公安交通集成指挥平台的数据通信。结合作者实际工作项目需求，选择公安部交通管理科学研究所开发的城市交通信号控制系统(HT-UTCS)与北京易华录信息技术股份有限公司开发的集成指挥平台(EHL ATMS)作为软件的通信双方主体。接口软件实现了以下功能：（1）交通信号控制系统和路口交通信号控制机配置信息的获取；（2）对信号系统状态、路口控制方式、信号灯显示状态等运行状态以及设备故障状态的实时监视，当路口状态发生变化时及时自动反馈；（3）可查看路口配时方案的执行状态和下达简单控制命令到信号机进行人工干预和控制；（4）实时交通流数据的自动上报和历史交通流数据的查询。软件使用跨平台的Java语言开发，在使应用层和传输层使用基于TCP/IP协议Socket网络通讯，在子网络层使用以太网接口，在实体层不做要求。软件兼容目前主流的各种操作系统及硬件平台，适用于目前主流的各类公安交通指挥中心的应用场景。2.      技术构架系统采用C/S结构，使用TCP/IP网络通讯协议，基于Socket通讯。在双方通信开始前接口软件作为客户端(Client)主动连接作为服务端(Server)的集成指挥平台，通信连接建立后不再区分客户端和服务端，双方对等通讯见图 10。考虑到系统的稳定性与实时性，接口软件采用Socket网络实时通讯与通用数据库访问接口相结合的方式同交通信号系统进行通信。对于实时性要求高，数据量小的控制命令，控制状态、实时交通信息等数据采用高效可靠基于TCP/IP协议的Socket通讯；对于实时性要求低、数据量大的信号控制系统基础信息、配置信息、历史交通数据等采用通用数据库访问实现，结构见图 11。 在开发技术方面，系统采用跨平台的JAVA语言开发，使用Apache开源网络通讯组件MINA实现网络通讯的封装，JDBC来访问信号系统数据库，SAX解析器解析XML文档。借助MINA的插件式网络协议编解码构架见图 12中的ProtocolCodecFactory部分，开发了XMLCodecFactory,XMLEncoder,XMLDecoder对象封装了基于XML的通信协议的编解码，实现接口软件与集成指挥平台的高效实时通信；开发了UTCSCodecFactory,UTCSEncoder,UTCSDecoder对象封装了HT-UTCS信号系统基于字节流的内部通信协议，实现接口软件与信号系统的实时通信。该构架灵活开放，扩展性好，通过替换或增加编解码部分(UTCSCodecFactory)可接入其他类型信号系统。3.      软件功能界面数据交换接口软件实际应用中部署在Windows平台上，以Windows系统服务方式在后台运行，软件本身没有用户操作界面，其最终功能体现在公安交通集成指挥平台的用户界面中，这里借助易华录公司的集成指挥平台(EHL ATMS)功能界面(见下图)来展示接口软件的部分功能，包括系统及路口状态显示、路口实时信息监控、故障报警、锁定阶段相位、警卫任务等等。 6.     总结通过采用统一、开放的数据交换通信协议，有助于打破信号控制系统封闭运行的现状，建立起与信号控制系统进行数据交换的渠道。公安交通管理技术的进一步深化应用也要求建立高度整合的公安交通集成指挥平台，实现包括交通信号控制系统在内的各种交通管理应用系统之间的互联互通、协作互助。本文通过研究提出了基于XML的通用、开放的交通信号控制系统与公安交通集成指挥平台之间的数据交换通信协议，并开发了相应的通信软件，在交通信号控制系统的系统级数据交换及系统集成方面做出一些探索和尝试，为今后各个交通管理系统之间的集成应用、为公安交管信息化建设的拓展打下基础。       基于该研究成果的通信协议及数据交换接口软件于2010年6月在苏州吴江市的公安交通指挥中心建设项目中投入了使用，通过实际的应用初步验证了通信协议的可行性与实用性，为后续的改进及通信协议标准化工作打下了坚实的基础。   参考文献1顾九春.城市交通信号控制系统数据交换标准研究D.北京工业大学,2005.52隋亚刚,张新城.基于公开通信协议标准的北京交通信号控制系统建设的研究与实践J.城市交通.2006,4:130-1333顾九春,陈 燕,赵万胜,苑金梁.基于XML的交通信号控制系统数据字典的研究J.计算机系统应用.2008,8:51-544Robert Rausch,Zhaowei Yang,“AN NTCIP-COMPLIANT NEXT-GENERATION TRAFFIC CONTROL SYSTEM FOR NEW YORK CITY”Z5中华人民共和国国家标准.交通信号机与上位机的通信协议S.GB/T 20999-20076NTCIP 9001.The NTCIP Guide.http:/www.ntcip.org/library/documents/pdf/ 9001v0406r.pdf,2009 作者简介徐棱，同济大学软件工程学院，公安部交通管理研究所助理研究员，主要研究方向城市交通管理、交通控制吴晓峰，公安部交通管理研究所助理研究员，主要研究方向城市交通管理、交通控制袁建华，公安部交通管理研究所研究员，主要研究方向交通管理、交通安全、智能交通系统