回顾信控领域过去的一年，“统一信控平台”可算是最热门话题之一了，行业内对统一信控平台寄予了越来越多的不切实际的幻想，似乎有了平台统一就能打通任督二脉，从此江湖一统、各大门派和谐共处天下太平；一些厂家的宣传中也有意无意在传达着这样的信息。

近一段时间多位业内同行也问过我的看法，概括起来大致包括几个方面的问题：“怎么看待统一信控平台？”、“能实现吗？”、“怎么实现？”、“实现哪些功能？”、“对提升交通控制水平有什么帮助？”、“真的可以兼容多种信控产品？”等等。

对这些问题我思考了很久，以下是我对“信控统一平台”的一些初步的认识，整理出来供同行参考。

统一信控平台能实现吗？

要回答这个问题，其实需要回答另外两个问题。

问题一：你要统一哪些功能？如果希望统一平台在功能无损的前提下完全取代现有信号控制系统，并且实现不同种类设备间无缝交互，答案是几乎不可能，一个必然的结果是“平台越统一、功能越损失”（后面我会详细说）；如果仅仅是为了实现绚丽的UI展示、简单人工控制干预、资产与运维管理等目标，其实实现并不难。

问题二：统一平台的用户（目标使用者）是谁？接上一个问题继续说，如果希望专业从事信号控制的交通工程师使用统一平台进行精细化的信号控制优化，几乎是不可能的，他们依然还要通过现场勘查、交通调查分析等手段，进行交通信号设计、控制模式设计，进行控制参数优化与标定工作，这些工作依然离不开专业的工具与原有的交通信号控制平台。

当然，前提是原有的信号控制平台具备不可替代的功能优势。如果希望为运维人员以及交通管理指挥调度人员提供简易界面，统一平台也许是个选择。但是，信号控制只是交通设施运维和指挥调度工作中涉及的一部分内容而已，通过原有控制系统提供接口，并在集成指挥系统中实现相关功能也许是更好的选择。

早在2013年发布的《公安交通集成指挥平台通信协议》（GA/T1049-2013）初衷就是要实现各类专业系统与集成指挥系统互联互通，而其中的“第2部分：交通信号控制系统”就是为实现集成指挥系统与信号控制系统数据交换。

综上，我认为统一平台能实现，但这是你想象中的那个统一平台吗？ 

统一信控平台是不是信号控制平台？

对这个问题的回答，一直以来我自己也很矛盾。

一方面，我认为统一平台能力有限，很难真正实现不同厂商的系统与设备的统一，不应该取代现有的信号控制系统。近期发布的《公安交通管理科技发展规划（2021-2023年）》之“主要任务14、加强交通信号联网联控”中所写：“联网接入不同品牌信号机，推进城市统一的交通信号管理平台建设”，我觉得这个命名中的“管理”两个字很有意思。

另一方面，我又认为统一平台首先应该是信控平台，应该具备信控平台的最基本功能要素，并以信控为基本应用目标。所以我们在讨论统一平台之前，有必要先对现有的信号控制平台有一些基本的认识。

交通信号控制系统通常由3个部分组成，分别是：前端系统（包括交通流检测设备、交通控制设备、交通信号输出设备）、通信网络系统、中心控制系统。

我们这里所说的信控平台所指的就是中心控制系统，它应该具备的基本功能包括基础数据管理、设备接入、状态监控、数据分析、控制优化、人机交互、故障监测、运维管理等功能，细分下去应该有数十项功能。

这些功能组成可分类为“辅助功能”与“核心功能”两类，辅助功能为用户提供道路服务水平监测、控制服务水平监测、控制状态监测、设备健康管理、数据辅助分析、可视化人机交互、人工干预信号运行等功能。

核心功能是采集并分析交通流数据、结合控制场景、控制目标，生成优化控制参数，并通过前端设备输出控制状态，以达到优化交通运行的目标。

随着前端软件技术尤其是数据可视化技术的发展，辅助类功能的开发已经变得越来越容易实现。所以，衡量与评价信控平台水平的关键指标不应该是界面的炫酷，而应该聚焦关键核心功能的水平与能力。几年前，我尝试着依据信控平台功能丰富程度、优化控制水平等方面的指标可以对信控系统进行能力评价。

下面是简单的表格（更复杂的信控系统评价指标以后有机会另文介绍）。

以这些粗略的指标来衡量，结果显而易见，目前的各类信控系统平台间存在着巨大的差异。在这样差异化的环境中，我们该如何建设统一平台？或者，以此为基准来审视我们期待的“统一平台”，我们希望建设哪一个级别的统一平台呢？

为什么“平台越统一、功能越损失”？

平台能力与价值最终取决于功能，因此要实现统一信控平台，首先要明确定义并统一功能范围。

粗略回顾一下中国信号控制系统的几十年的发展历程，目前在国内运行的信控系统既包括国外引进系统（美国、英国、西班牙、澳大利亚等）、也包括在引进系统基础上边仿制边开发的产品（如美国血统的类NTCIP系列产品等），还包括完全自主体系的各类产品。这些产品与系统从前端设备、通信协议、到中心平台功能之间都存在着巨大的差异，对一些最基本的交通控制概念的理解也各不相同。

以前文所说的核心优化功能为例，各系统厂家都将自己的研究成果和对交通控制、优化的理解融入了产品之中，如scoot系统的秒级实时自适应优化、scats系统基于类饱和度的方案选择优化、NEMA基于环结构体系的以丰富多样的感应控制为核心的优化方法、以及很多国内厂家的方案自动生成类优化方法，加之各种公交优先控制、紧急优先控制、逻辑组合控制、场景化时间响应控制等等，近期出现的基于边缘计算的分布式优化控制方法，这些控制方法不仅在优化原理上差别巨大，包括对交通控制最基本概念的认识也存在巨大差异：

信号控制基本概念中对灯组、相位、阶段、环的定义，路网模型中流向、路段、路口、区域（子区）的定义与理解千差万别；

协调控制中协调相位、相位差（绝对、相对）、协调方式（绿初协调、绿尾协调、绿中协调）等概念理解各异、处理各不相同；

控制方案切换、控制模式转换过程中的过渡处理方法迥然相异，凡此种种无法细数。

再加上不同控制系统的优化目标、控制算法模型差异，系统通信协议、控制颗粒与实时性差异，都为统一平台建设提出了种种挑战。

下图中ABC分别表达三种不同的信号控制系统产品的功能范围，有两种方法实现统一平台，或实现三种新系统的功能合集，统一平台功能涵盖ABC全部功能，或实现三种系统功能交集，统一平台功能仅涉及ABC交叉部分的共同功能，首先要明确实现哪种统一？

合集实现，我们要实现3种系统全部功能，并实现交叉控制，也就是说通过统一平台要能够实现原有控制系统的全部优化、控制功能，且不说开发一套平台实现全部scoot系统、scats系统种种L4级系统功能的可能性有多大，就算是把最简单的L1-L3级系统功能全实现一遍难度也可想而知。

几年前，我曾经有过这样的动念，甚至雄心勃勃设计了庞大的数据结构与流程，但最终还是“兴兴开始、悄悄放弃”，实在太难了。

交集功能，这就要分析一下各类系统能够有的交集部分的功能有哪些？逐一梳理后，我发现剩下的功能基本上是配时管理、故障管理、状态监控、人工干预控制（统一特勤控制属于此功能）、数据可视化、以及一些档案管理类的功能，仅此而已，充其量是信控系统的L1水平。

即便如此，由于不同系统基本概念、编码命名方式、故障类型定义、数据统计的时间空间颗粒等仍然有很多鸿沟，在表达上也还在很多难题，就连最简单的配时方案表达就很难实现“相位-阶段”、“相位环-相位”、“色步结构”之间的统一表达，即便有某些厂家号称解决了这些问题，我也只能无语一笑，因为他们面对的只是固定配时的定周期场景，一旦涉及全感应控制、实时自适应控制、协调感应控制、优先控制等场景，以及动态的相位搭接、GapOut、Force-off、Resting Red、相位阶段按需出现等优化模式试试？估计全部原形毕露。（这是另一话题，在此不深谈，以后有时间可以单独写写控制模式与控制方法的差异与对比）。

所以，冷静下来，统一信控平台似乎更适合实现功能交集部分。鉴于前面的分析，这些交集部分的功能似乎很难包括核心优化控制功能，更多的是辅助管理功能中的一部分而已。

统一平台的功能

统一平台概括起来要实现以下几个方面的统一：

统一接入：通过对平台间的开放接口协议（如GA/T1049.2）或信号控制设备的开放接口协议（如GB/T20999或NTCIP），实现信号控制向统一平台的接入，建立不同系统间的数据交换、命令控制交互；

统一监视：利用统一的GIS地图、统一的UI界面实现设备状态监视、控制运行状态监视、交通运行状态监视等功能；

统一操控：将不同控制理念的配时数据归一致化，并以统一的人机交互界面实现部分配时参数管理；统一控制干预界面，包括特勤控制、紧急干预控制等；

统一基础数据：统一的路网定义，实现涵盖车道、路段、路口、道路、控制子区、区域、城市的全路网统一定义；统一的设施档案管理，实现交通检测设备、交通信号输出设备、交通控制设备、通信设备、中心系统等在内的系统资产数据统一；统一控制数据管理，实现基础控制参数、安全参数、优化标定参数、配时数据等控制数据统一；

统一交通数据：在统一路网的基础上，对交通数据在空间范围、时间颗粒上进行归一融合，实现交通数据的统一清洗净化、统一预归档处理、统一存储、统一分析、统一可视化展示；

统一接口：交通控制应用越来越多需要与外部系统进行数据交换，统一平台应该对外部数据接口进行统一规范管理，实现与外部系统的数据交换与控制交互；

统一安全：应建立统一的用户身份认证与授权管理体系，这其中既要包括人员安全认证与授权、也包括设备身份认证预授权，还要包括接口认证与授权；建立统一的运行操作审计日志；

统一运维：建立统一的故障分级分类代码体系，通过对不同系统设备故障进行归类转换，实现统一的故障报警、处置、维修维护全流程管理； 

协议问题是统一平台的关键问题吗?

先给答案：不是！

再解释，协议与接口是统一信控平台要解决的重要问题，但不是唯一问题，更不是核心关键问题。

一个有趣的现象是每当谈到统一平台，很多业内同行第一反应就是开放协议，但是协议开放了就能实现平台统一吗？

以NTCIP协议为例，协议文本以及标准的MIB库天然就是公开且开放的，国内的GB/T20999协议也早就发布了，国内一些主流信号控制系统厂家其实也是能提供数据接口的，但是为什么统一平台依然是个难题？

系统协议就如同人与人之间沟通的语言，语言相通并不意味着交流顺畅、能力对等、或思想一致。协议与接口开放只是解决了基本的通信问题，并不能解决控制方法、控制理念问题。

协议与接口打通只是实现了IT层面的数据交换，并不能解决交通控制层面的协同与统一，前面说到的控制概念、控制理念、优化方法上的差异并不会因为协议打通而得到有效解决。

因此，那些“能打通多少种通信协议、接入多少种信号机与信号系统”的说辞都无外乎是一种宣传噱头，因为从IT角度来看，接入协议并不是什么高深的技术。

真正的难题是理解协议背后的控制逻辑与控制理念，以及这些逻辑理念在交通控制上的意义，这才是最大屏障。

要想从根本意义上实现统一信控平台，必须从基础标准、基础方法、基本理念上进行统一与规范，只有思想统一才能实现系统与控制的真正统一，真到了那一天，其实也就没有必要再做什么统一平台了。这条路还很漫长，而且历史包袱越来越重，对此我不持乐观态度。

关于协议这个话题，可以参考之前我在赛文发过的一篇相关文章。( 需求并起的信号统一联网联控 | 张福生：说说信控通信协议)

统一平台的知识产权问题

延续上面关于协议的话题，江湖传闻某些统一平台的做法是采用暴力破解的方式，以反向工程的方法对某些不开放的系统进行协议破解，这种做法是否涉及知识产权方面的法律问题，我表示疑虑。

统一平台的几种基本架构形态

统一信控平台要实现多种异构的信控产品的融合，基本方法上无外乎两种方式：C2C（中心到中心）模式与C2F（中心到现场设施）模式。在具体项目实现上可能还会存在两种模式的混杂模式。这其中涉及大量琐碎的技术细节，不一一赘述，以下用几张示意图简单表达。

传统经典的信号控制系统基本是采用树状结构，如下图：

C2C（中心到中心）平台模式，需要信控系统提供接口并开放中心接口协议，如下图：

C2F（中心到现场设备）平台模式，需要信号控制器提供开放的通信协议，如下图：

混杂接入的平台模式，针对不同的开放协议灵活选择适当的接入方式，如下图：

统一平台就能统一控制吗？

我认为：既能又不能。

说能，是指通过统一平台可以在一定范围内统一修改控制参数，比如简单修改配时方案、时间计划表；统一进行人工控制干预，比如中心远程锁定相位、集中进行勤务路线控制；某些特定场景下可以实现协调控制等等。

说不能，是指即使有了统一平台也未必能实现不同信号控制产品间的有效协同，跨产品的绿波控制、方案优化控制、优先控制、事件响应控制等功能仍然会存在各种问题，各产品独有的控制功能更难统一协同控制，即使勉强拼凑，也只能适应局部特定的控制场景，一旦场景变化往往需要交通工程师做大量的适配性工作。

统一平台很难实现异构系统间的无缝融合。

仅以绿波控制为例，不同信号控制器或控制系统在方案切换时的过渡与同步方法、过渡转换周期数量几乎完全不同，协调相位的定义与协调时机也各有理解，这些差异源自产品最底层设计，很难通过统一平台进行协同（以后似乎可以做一个专题来写写不同信号系统产品的协同控制差异）。

关于预算与造价

过去一段时间我收集了一下国内关于统一平台的招投标信息，从掌握有限的公开资料来看各地统一信控平台的造价少则百万、中则数百万、高则几千万，不同预算往往意味着不同的功能需求，但不可否认的是很多城市最终解决的只不过是几十台到几百台不同品牌信号机的统一管理而已。同样的预算是否还有其他的解决方案？我不知道。

要不要建设统一信控平台？

这是终极问题，回答前再想想前面的问题：要统一什么？给谁用？预算值得吗？

别冲动，别盲目，再想想。 

这篇文章写写停停了好多次，期间与清华大学李瑞敏老师、滴滴智能交通孙伟力老师有过多次讨论，他们提出的问题与想法给了我很多启发，在此表示感谢。 

终于写完了，忽然想到一个不恰当的比喻，统一平台也许像手机的拍照功能，专用控制系统更向像是单反相机，用手机拍照简单易学还有美颜功能，但是专业的事情还得专业工具支持。再好的工具也离不开摄影师的审美与构图，别指望工具本身，交通控制的灵魂永远依靠交通工程师的灵感与辛勤。

其实还有几个当初列出的问题没有回答，先mark一下，也许以后可以写个续集：统一信控平台与交通信号大脑的关系？怎样通过统一平台实现控制能力提升？有了统一平台，就可以不再受制于某一个厂家了吗？以及本文中遗留的一两个内容：控制模式与控制方法的差异与对比，不同信号系统产品的协调控制差异。