2025年11月19日~22日，2025中国智能交通大会在海口隆重召开。2025年11月22日的道路交通控制与优化论坛上，北方工业大学智能交通控制（北京市）重点实验室张福生研究员就《Peer-to-Peer对等分布式交通信号控制》做主题分享，本文系现场演讲整理而来，未经本人审核，如有错漏，敬请谅解。

张福生：过去一年我做了一件事。2024年同样的会议上，我曾分享学习MUTCD的心得，之后我用一年时间，系统阅读了STM交通信号配时手册以及NTCIP的V3版本，V3A、V3B直至刚发布的V4C版本。我希望能从中获得一些灵感，探索交通信号行业未来还能做哪些事情。

一、关于P2P点对点

一个很热门的词：P2P点对点。在交通信号控制领域，常用的控制模式以往基本集中在感应控制、协调控制以及系统控制这几类。感应控制大多依赖本地线圈检测器，感知交通流并快速响应；协调控制则更有趣一些：实现协调控制需要几个基本要素，第一是共时钟，第二是共周期，在此基础上才能完成协调。似乎并不完全正确，要协调的本来是交通流，可实际操作中却往往是按照预设的时间去执行；本应协调的是交通流本身，却不得不先去统一周期、同步时钟。以前在西门子从事信号机研发时，协调控制模式为无电缆协调。只要拥有共同的时钟，就能实现协调。但现在交通信号协调具备了通信能力，既然有了通信，为什么还要拘泥于这种方式？上下游的状态能否互相感知？

另一个值得思考的问题是：控制系统是否必须有一个中心？是否一定要采用树状结构，层层向上，从下层信号机到分中心再到中心……这样的架构真的适合交通控制吗？当前进行协调控制时面临一个难题：方案切换时需要过渡。无论是增周期过渡、减周期过渡还是驻留过渡等，每台信号机根据其当时的具体情况，都可能选择不同的过渡方式。这也导致了方案切换时可能出现短暂的混乱等现象。

这些问题究竟该如何解决？明年可能发布的交通信号配时手册第三版，目前已有草稿，其中大量提及了点对点控制、可定义逻辑控制等方向。

点对点的控制模式，基于路口间的直接通信。目前的实践中，两个信号机明明紧邻，彼此之间却不通信，这是一件颇为奇怪的事。传统的控制系统更像一个指挥系统，上层有司令员，指令层层下达到具体执行者，类似于企业中的金字塔状结构。但交通并非如此。《开车心理学》有言：交通是千千万万人参与的一场心理博弈。即交通是一个自由博弈的结果。控制系统应当沿用这种金字塔式的树状结构来控制，还是可以像微信那样，实现一种扁平化的协同控制？这是一个非常值得探讨的话题。

二、P2P控制的构建逻辑

接下来需要做的事情大致包括以下几个方面：首先，将控制器转化为独立的决策单元，使其能够与上下游进行通信，从而实现一种去中心化的控制方式。上游路口不仅能将检测到的交通状态及自身控制状态直接传递给下游，下游也能综合这些条件作为控制决策的依据。实际上这种控制方式此前就有，即所谓的主从控制。曾经在一条干线或一个区域中，设置主信号机来带动若干从信号机协同运行。而在扁平化的点对点模式下，这个“主”角色并非固定，而是可以构建出一个能动态选出主导角色的系统。

基于这个构想，我们在北京周边的燕郊进行了一个小型实验，尝试建立一种平行的架构，让各个路口之间能够相互通信。一个典型的应用场景如下：在重大活动期间，交警经常需要到现场进行手动控制，但一名交警通常只能控制一个路口，这在实际中颇为尴尬。因为有时控制这个路口需要与上下游路口协同配合，而现在的情况往往是一边操作信号机，一边用对讲机呼叫协调，这是一种相当奇特的现象。能否让一名交警在控制一个路口时，也能便捷地联动其周边路口？这其实并非难事，但以往却一直未能实现。

要实现这一目标，就需要建立一套相应的逻辑。因此，包括NCIP V3、V4版本，以及现在许多厂家新一代信号机，其手册中新增了两个关键部分：一是点对点通信，二是可编程逻辑。未来交通信号控制若要实现众多优秀算法并让信号机有效运行，不仅需要高级的算法支撑，更离不开底层执行机构执行诸如“如果怎样，就向谁发送消息，应如何响应”这样的基本逻辑。这套底层逻辑，实际上更接近于工业控制系统中的工业组态，也并非一项特别困难的技术挑战。

基于这一点，面对交通领域中如此众多的特殊场景，是否有更普适的解决方法。

以往一些厂家在遇到一些特殊场景时，解决方案往往是开发一个新版本。某小型城市，80个路口的80台信号机竟有24个不同的软件版本。既然如此，能否通过可编程逻辑的方式、以可定义配置的方式来实现统一应对？

实际上完全可以。当然，从交通控制的具体应用角度来看，如何运用点对点方式，其核心挑战在于路口与路口之间究竟应如何协同。该如何实现无周期、或变周期的协调？如果最底层的控制逻辑框架无法突破，那么在其上叠加再多的智能体或边缘计算，边缘计算也可能因目标不清而迷失。

因此，在着手构建系统并进行一系列实验后，我们认为，一个理想的点对点控制系统应具备以下特征：能实现精准优化；控制模式可更频繁地切换；面对交通事件时，做出更迅速的响应。

举一个例子，目前的溢出控制多为被动响应。车辆是从上游来的，为何到了这里才溢出？在它到来之前，下游为何不知情？或者说，如果上游知晓下游的通行能力，本不应放入过多车辆。我们不应局限于被动响应的逻辑，而应更主动地去解决这个问题。这些方面，通过点对点的方式，都有可能找到实现的路径。

另外，在韧性方面，当前的控制系统多采用树状结构，对中心存在强依赖。如果一个系统不依赖中心，那意味着其中心并未发挥关键作用；若中心确实发挥作用，那么系统必然高度依赖于它。然而，一旦中心崩溃，整个系统将面临何种问题？在这些方面，依托点对点、对等控制的方式，或许能找到解决问题的答案。

接下来是关于建设成本的问题：产品和技术在一个项目中所占的成本往往不到一半，大量的成本实际上消耗在工程部署和后期运维上。如何有效降低工程成本，是一个相当大的挑战。在这样的系统框架下，如果在一条道路上临时增加一个路口，就需要新增大量工作，系统中许多参数必须重新配置，也要完成繁重的设置。这项工作能否变得更快捷？

三、未来系统演进

展望未来，能否实现交通信号控制系统——从检测器、控制器到整个系统便捷部署，并快速投入运行？如果沿用传统的树状结构，即插即用很难实现，因为需要调整的参数过多。而如果采用扁平化、去中心化的系统架构，应该能找到更优的解决方案。

控制颗粒度的问题也同样重要。例如，这么多年来公交优先等各种优先通行系统上效果不尽如人意，其中一个原因在于当前的控制颗粒度是以周期为基本单位的。需要中心生成方案，下发给信号机再去执行，这是固有的模式。一旦引入优先请求，就会打乱原有的协调，导致优先控制往往停留在理论层面，实践中难以真正落实。

这里可以简要回顾NTCIP标准的发展历程。早在2005年的v2版本中就曾提及，未来可能需要实现点对点通信，但当时并未明确定义。到2014至2019年推出的v3版本中，v3a提到因通信网络条件尚不成熟，暂时搁置该议题；而v3b则明确点对点功能必须在下一版本中实现。至2020年左右启动编写的v4版本，已于去年正式发布，其中明确支持可编程逻辑与点对点应用，强调信号机之间水平横向通信已成为必须支持的能力。

未来将发布的新版《交通信号配时手册》（STM）中，设有专门章节论述点对点协同、通信与控制的相关内容，同时，标准也将部分内容独立划分至1211与1209章节，都包含大量与点对点相关的规范。事实上，不少厂商也已在此领域展开实践，例如美国一家知名信号控制企业，现已与交通仿真公司合并，共同开展相关探索。若查阅该厂商最新一代信号控制系统的手册，可发现点对点（P2P）通信已被作为一项重要的功能模块。也有公司在美国版本的M60系统中构建了名为“下一代交通信号机”的体系，同样致力于点对点交互能力的实现。此外，MaxTime软件及其他众多厂商也都在开展相关探索。业界已出现诸多类似尝试，这无疑值得借鉴与关注。

当然，推进点对点架构也面临诸多挑战。

首先，在原有的中心化强通信模式下，信息安全问题相对容易解决，未来通过通信认证、加密等手段可以形成较好方案。但一旦转向点对点水平通信，安全防护的形态将发生根本变化。

其次，控制方法体系也需相应调整，包括配置方式在内的许多环节都需要改变。我们此前在一些验证性项目中尝试运用博弈论等方法，使节点之间通过自主博弈选择方案，仅是初步探索；总体而言，这必将带来一系列方法论的革新。

此外，工程实施方式同样需要变革，并对相关标准产生较大影响。现行信号通信与信号机系统的标准大多围绕中心到现场（C to F）或中心到中心（C to C）的交互制定，但目前缺乏现场到现场（F to F）——即信号机之间、入口与入口之间——的直接通信规范。填补这一空白将可能带来更多挑战，但也正是未来系统演进的实际需求。

无论是控制系统还是管理系统，长期以来信息流与交通流在结构上相互分离、各自独立。未来，我们的控制流与信息流应当能够伴随交通流在网络中协同运行，以一张信息网络覆盖交通实体网络，使信息流得以实时贴合交通流的动态。希望这样的系统在可靠性、复杂场景自适应等方面提供新的解决方案。目前相关探索仍处于初步尝试与开发阶段，待经过一段时间的实践与积累，我将把这项工作进行系统梳理，并分享更完整的思考与成果。