于是，如何实现多协议异构系统互联再次引起行业的关注热点，“信号控制器与上位系统的通信协议“又一次成为关注的话题。

协议是什么？协议应该起到什么作用？怎样理解不同协议之间的差异？怎样才是一个好的协议？怎样实现不同协议间的转换与互联？回答这些问题涉及网络通信、数据编码、交通信号控制基本概念、基本方法等很多层面的非常复杂的技术细节。

所以，几年来我多次尝试着用最通俗易懂的方式来进行解释，但每每写不下去；今天重拾这个话题，希望能用最通俗易懂的语言和轻松的方式来把过去的一些研究理解梳理出来，供同行们参考。

将近二十年前，刚开始进入交通控制这个领域，我做的第一件事情就是做协议相关的开发工作。那个年代交通信号控制系统中能够联网运行的基本是国外引进的系统，包括西门子的SCOOT系统、澳大利亚的SCATS系统。

联网的方式基本上采用电话专线通信，以西门子SCOOT系统为例，中心控制系统采用通信前置机（TC12）驱动调制解调器阵列，并通过电话专线实现与路口信号控制器的OTU之间的通信，通信速率1200波特率。

也就是说路网上每一个路口的信号机都通过一条电话线直连到中心的TC12接入服务器上，对于大中型城市一个信号控制系统的接入单元要占用几个机柜，里面连接着数百上千条电话线。

但是，随着城市规模的扩大，电话专线有限的传输距离限制，造成很多远距离路口无法接入系统（这也是scoot、scats系统采用了主控、分控的方式进行就近接入，但仍然不能满足要求），同时，电信行业“铜改光”的影响下电话专线业务逐渐被取消。

本世纪初，随着数字通信网络的普及，我们开始尝试对原有信号控制系统进行升级，采用基于IP网络取代传统的电话专线通信。

第一个尝试在大连的SCOOT系统上进行，为分析SCOOT系统与TC12前置机、TC12与路口信号机、路口信号机通信单元与控制机之间通信协议，我们专门开发了网络监听软件、同步通信监听设备、并行总线数据旁听装置，用于旁路分析通信各个环节的数据。

同时，对照分析中心系统、信号控制器端控制响应状态，掌握了数据通信格式、时序，并专门设计了基于IP通信的中心通信单元（ICU）、信号机端通信单元（OCU），分别用于取代中心系统的TC12以及信号控制器端的OTU通信板卡，实验运行取得了良好的运行效果，系统和设备开发过程中得到了时任大连交警支队姜廷顺副支队长和西门子公司的大力支持，相关的产品后来成为西门子公司的标准产品，成功适配了于多种西门子信号控制器（ST800\ST700\ST400），先后应用于大连、承德、北京、成都、武汉等很多城市，至今累计运行路口已经达到数千个。

回顾上述产品的开发过程，表面看是对原有通信协议进行解析、重新封装，并完成由裸协议向基于IP的网络协议的迁移，但其中最重要的工作是对原系统信号控制理念、概念和方法的理解，并将其对应到通信协议的表达上。

也正是通过这个过程，我们开展了对以scoot系统为代表的英国交通信号控制通信协议，并以协议分析为开端，从最底层的一个字节一个比特开始深入研究了英国交通信号控制体系、相关标准、控制方法、控制理念。

在此之后，又进一步研究了美国的NTCIP、英国的UTMC、德国的OCIT等多个国家交通协议，后来也参与了国内“交通信号控制机与上位机间通信协议”（GBT20999-2017）的编写，其中很多体会、很多故事、很多细节内容，以后有机会另作专题分享。

通信协议是什么

要清晰理解通信协议，绕不开一些晦涩难懂的概念，以下引号中内容来自百度：“通信协议是指双方实体完成通信或服务所必须遵循的规则和约定。

通过通信信道和设备互连起来的多个不同地理位置的数据通信系统，要使其能协同工作实现信息交换和资源共享，它们之间必须具有共同的语言。交流什么、怎样交流及何时交流，都必须遵循某种互相都能接受的规则。这个规则就是通信协议。”

为实现通信协议的标准化，国际标准化组织ISO 于1981年正式发布了网络系统结构--七层参考模型，也被称为开放系统互连模型(Open System Interconnection，OSI)。

模型中定义了“物理层(PH)、数据链路层(DL)、网络层(N)、传输层(T)、会话层(S)、表示层(P)、应用层(A)“，这个标准模型的建立,为各应用领域的协议标准化提供了参考，大大推动了网络通信在各行各业中的应用于发展。

通俗形象解释一下这几个协议分层，以我们最常见的电话会议为例：电话线路是物理层（PH）保障信号传输、声波到电信号的转换以及在线路上传递是数据链路层（DL）、电话拨号寻址建立的两端连接机制是网络层（N）保障我们找到对方、人类的嘴巴和耳朵实现发声和听音是传输层（T）保障我们发出和感知声音、会议双方都说同一种语言（中文或英文）是会话层（S）让我们建立最基本的沟通方法、双方讨论同一领域的专业问题并用到的那些默认互相理解的专业术语是表示层（P）、最终通过通信要达到的会议目标是应用层（A）。

现在，我们看看交通控制领域里，通信协议主要目标是实现交通信号配置参数上下载、信号运行状态上报、交通数据上传、控制命令下发、故障信息上传功能。

对照OSI七层协议的规范，这些功能基本上是在表示层（P）和应用层（A）上来完成。因此我们在制定法相关协议标准的时候就应该将注意力专注于表示层和应用层，其中最关键的就是对基本语义的定义，以下是关于信控通信协议的几点想法。

 通信协议只是数据定义，应用与业务才是核心

任何通信协议都只是对一种应用领域目标属性以及传输方式的定义。通信协议的背后是应用领域基本概念的定义、以及应用场景、应用模式的归纳与总结。

交通控制领域也同样，在没有完整而清晰定义最基本概念、最基本方法，没有明确规范控制模式、描绘应用场景的情况下，通讯协议的规范就无从讨论。

这些基本概念、基本方法既要来自行业应用经验的积累、更要进行抽象、概括和总结；简单地将各种需求收集到一个大箩筐里，试图包罗万象，只能使通信协议越来越臃肿庞大，即无法实现异构系统设备之间的互联互通，也不利于行业创新发展。

以美国NTCIP协议为例，NTCIP协议严格遵守了OSI七层协议的规范，采用MIB表的方式对所有最基本语义进行了定义，如NTCIP1201对交通领域里的基本目标属性进行了定义（如时间计划表、日志、事件、基本操作等），NTCIP1202对交通信号控制器的基本目标属性进行了定义（如相位、灯组、配时方案、交通检测器等）。

这些定义规范了目标的属性、值域范围，并没有描述这些目标属性在交通控制上的意义、控制的应用流程与方法。

一个例子是，即使通读了NTCIP1202全文，仍然理解不了环结构的控制要义，仍然搞不懂为什么NTCIP中没有定义相位冲突关系，为什么没有绿间隔定义，以及感应控制、协调控制的基本方法，尤其不知道这些数据到底怎样传输，数据传输的时序、完整性怎样保证。

原因在于，我们看到的NTCIP协议文本只定义了数据目标属性的基本描述，而没有看到支撑NTCIP协议背后的美国交通控制领域一系列标准规范组成的完整体系，没有看到支撑NTCIP协议的一系列数据编码、传输、互操作的基础通信协议。

正因如此，很多人看NTCIP往往是一头雾水，很多国内的信号控制器号称兼容NTCIP协议也只能是照猫画虎，只有参数读写，没有实现真正意义上功能兼容。

要想在应用层上理解美国交通信号控制的要义，还需要通过其他标准进行定义，需要参考NEMA相关的系列标准（很庞大的体系，不再本文讨论范围内，以后再说）。

另一方面，我们看到NTCIP协议文本中并没有定义数据报文封装格式，也没有描述所谓的“报文头尾“、”长度“、”校验“、”转义码“等等内容（这些内容在OSI模型的底层架构中已经充分保证，无需应用层关心），而是非常好的借助于网络通信领域成熟的技术框架，进行了更加专注于应用的协议定义。

NTCIP基于SNMP网管协议，底层是UDP协议、IP协议，严格准守了OSI七层协议规范。因此在产品开发和实现协议互联上可以充分利用IT领域成熟的工具、方法以及大量开源的代码实现高水平的协议层开发，让开发人员直接面向业务进行产品研发。

同时，由于采用了标准化的基础协议、数据标记定义方法，也为未来协议扩展、升级、传输安全保障等奠定了良好的基础。

与NTCIP类似，英国最新公布UTMC协议也是基于OSI模型，采用SNMP协议为基本框架，以MIB表定义“基于Phase in Stage“的实时控制中各类命令字、返回字的传输控制方法。

国内信控通信协议的现状

国内最早公布的第一个信控通信协议是《交通信号控制机与上位机间的数据通信协议》（GBT20999-2007），该协议定义了信号控制机基本参数配置、控制、状态、交通数据的传输规范。

但是尴尬之处在于，这个协议既想引入美国的环结构、又要保留我们传统的相位-阶段结构，因此在很多基本概念、基本方法的定义出现严重歧义，在实践过程中陷入各种困境。

继GBT20999-2007之后发布的GB20999-2017，虽然对一些容易引起歧义的概念、属性进行了一定的澄清，但仍然受单一标准的局限性限制，无法对目标属性以及在交通控制中的含义进行精准定义，因而在应用过程中依然困难重重，造成很多厂商需要进行大量私有协议扩充，才能完成产品目标。

过多的协议扩充造成的结果是表面同一标准，但兼容性极低的现象。

行业内，另一个准强制的协议是来自《道路交通信号控制机》（GB25280-2016）附录A“指令和消息格式“，这部分协议定义了一个基本数据包装框架，对交通信号控制的内涵目标与属性没有进行任何定义，本质上无法应用于异构系统间的互联。

更为严重的问题是，这几个版本协议都是从最基本的数据封装开始进行底层定义，严重背离了OSI标准模型，成为完全孤立于现代网络通信主流技术之外的特殊存在。

这种结构设计对协议的推广应用、产品兼容开发带来极大困扰，每一个版本协议的推出都让开发人员陷入对基本格式框架的纠结，而无法专注于核心信控技术的研究。

与信号控制机通信协议相对应的是交通信号控制系统间互联的协议，目前比较成功并具备一定应用规模的是GA1049-2013《公安交通集成指挥平台通信协议》，其中的GA1049.1-2013《第1部分：总则》规定了基本的数据交互操作方法，GA1049.2-2013《第2部分：交通信号控制系统》以XML超文本语言定义了系统间交通控制状态、数据、命令的互操作目标及属性。

但是，该协议同样存在数据目标属性与操作混杂、部分基本概念定义含糊、关键业务流程不够清晰的问题；同时由于XML数据定义本身存在的冗余问题，导致面对大数据量互传需求的实时性无法保障等问题，因此，仅适合非实时的管理、监视场景，面向实时控制的需求时性能问题成为该协议的短板。

另一方面，这些分层架构不清晰的通信协议，也为安全保障带来了极大困扰，一些标准化的数据传输加密方法、数据认证方法无法应用于交通信号控制领域。 

怎样定义一个好的信控通信协议

一个好的通信协议应该具备以下基本要素：

1. 与行业领域其他标准契合

通信协议一定不是孤立存在的，它承载的是一个应用领域各类标准规范所定义的基本行业共识，在交通控制领域，通信协议的基础是交通控制最基本概念、目标、属性的清晰定义，并通过标准进行规范。

2. 符合最基本常规技术框架

交通控制协议只是通信应用中的一个具体场景，要以OSI协议默写为基础，充分利用成熟的网络通信技术，选择合适的协议框架是必由之路。尤其是随着5G、物联网技术、车路协同、网联汽车领域技术的飞速发展，通信领域基础通信框架与方法不断迭代更新，如果不能利用这些成熟技术与方法，信控协议必然游离于主流之外。

3. 专注于应用目标，适合信控需求

针对信号控制领域对数据传输实时性、关键数据完整性的需求，结合具体目标、属性的特点对数据互操作模式进行定义。

4. 具备扩展性

为未来协议扩展以及企业自定义扩展预留协议空间。

5. 原生安全性

应支持开放的标准化的安全体系，实现基于设备身份认真、传输安全保证的安全体系。只有支持标准OSI框架的建立在标准协议基础之上的协议才能真正做到可验证的原生的安全保证。 

关于信号控制协议标准的几点建议

1. 参考世界各国相关领域标准

他山之石可以攻玉，必须承认在交通控制领域标准化程度方面，我们与欧美主要国家之间存在巨大的差距，闭门造车永远无法实现追赶与超越。

在制定我们的协议标准与规范之前，需要认真研究学习他人的成熟经验，学习他们的标准体系，学习他们的协议架构，这方面我们的了解和研究还差的很多很多，能够讲清楚各国交通信号控制标准、通信协议内涵的人少之又少。

2. 处理好产品兼容与标准一致

制定信控通信协议现实的难点在于既要兼容存量系统设备，又要实现未来的标准统一。

这就需要认真研究交通控制的本质要素与核心需求，从最基本概念、方法、属性入手补基础课。简单网罗现有产品、系统特性，试图靠扩大协议外延实现兼容各类产品的目标，外延越大内涵越少，最终只能是一锅“乱炖“。

3. 充分借力网络技术的发展成果

认真参考OSI模型，借鉴网络通信领域的成熟可靠的成果，采用符合国际通识、国家标准的专业化的形式语言标记方法来定义与描述信控领域的数据目标、定义通信协议（如参考OSI框架的ASN.1抽象语言标记标准等），一个合理的方式是行业专家定义需求、通信领域专家定框架。

4. 充分借力IT技术的最新发展

参考借鉴互联网、物联网领域的最新技术，如MQTT技术、大规模消息服务技术等成熟方法，充分享用专业领域发展成果，站在巨人肩膀上做研究才能站得高看得远。 

结束语

信控通信协议绝不仅是数据传输格式定义，它是交通信号控制技术发展与标准化程度的集中表现。

作者 | 张福生，北方工业大学城市道路交通智能控制技术北京市重点实验室研究员，信控中国俱乐部会员，点击下面【阅读原文】报名加入信控中国俱乐部