交通信号控制系统跟公安交通 集成指挥平台通信协议研究探究文档.docx
《交通信号控制系统跟公安交通 集成指挥平台通信协议研究探究文档.docx》由会员分享，可在线阅读，更多相关《交通信号控制系统跟公安交通 集成指挥平台通信协议研究探究文档.docx（22页珍藏版）》请在冰点文库上搜索。
交通信号控制系统跟公安交通集成指挥平台通信协议研究探究文档
交通信号控制系统与公安交通集成指挥平台通信协议研究
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层模型结构
OSI7层模型是现有计算机网络应用的基础，目前广泛应用的各类计算机通信协议都是基于它设计建立的，例如著名的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
序号
元素名
说明
1
RegionNo
区域号（从1开始）
2
CrossNo
路口号（从1开始）
3
CrossName
名称
4
Feature
特征
5
DetNoList
检测器号列表
6
DetNo
检测器号（从1开始，在单个路口中唯一）
7
LaneNoList
车道号列表
8
LaneNo
车道号（从1开始，在单个路口中唯一）
9
PhaseNoList
相位号列表
10
PhaseNo
相位号（从1开始，在单个路口中唯一）
1
升级会员 