孙旭飞：对国标《道路交通信号控制系统通用技术要求》的建议
2016-10-31 17:16:40 来源：www.its114.com 作者:孙旭飞评论：0

　　一、前言

　　我在福州大学任教前，曾在日本东京一家交通信号领域的著名企业从事了10年道路交通信号控制系统的研发工作，担任过主任工程师，做过系统主要环节的结构设计和软件设计工作。因此，对日本新道路交通管制系统的体系十分熟悉，无论是系统功能、系统构架、软件构架、协议格式、各控制软件组织方式，或是信号机硬件结构都十分了解。在日本国家，无论是信号系统还是信号机，安全、稳定和可靠都是第一的，在这方面我国与之相比还有一定的差距。因此，我想借此机会先简单介绍一些在这方面中日间差异较大的地方日本国是怎么做的。这或许有助于对我后面建议的内容理解。

　　一、对系统服务器的安全要求：一个区域信号控制系统由3类设备组成，其一是装备后台控制程序的服务器，一般装备两台，一台日常运行，一台待机备用，给终端信号机的任何指令均由前者下达。它的后台控制程序由近百个各司其职的进程组成，该服务器上除了操作系统，几乎没有其它与信号控制无关的软件。系统运行中，只要一个进程出现异常，该服务器就自动重启。若是这台服务器损坏，重启不了，待机状态的备用服务器立即自动顶替上去。其二是装备情报管理程序的服务器，系统参数的配置与管理在这里实施，交通流的报表（年报、月报和日报等）也在这里编辑、参阅和打印。其三是中心控制台上的普通PC终端（多台），其装备的相关应用软件是人机对话程序，用于操作员通过视窗界面对系统状态或交通流量进行监视和人工干预。这样把系统一分为三的做法，可以减轻担任信号优化处理服务器的负担，降低软件故障对信号控制的影响，提高了系统的稳定性和可靠性。

　　二、对终端信号机的安全要求：把支持信号机运行的路口特征数据区别于其它运行参数，而作为特殊数据来管理。路口特征数据包含了该路口几个相序方案的灯色信息和安全时间，由于该数据关乎路口的通行安全，绝对不允许出错，所以被禁止通过网络进行远程下载。而其它的运行参数则没有此类禁令。另外，信号机的控制部采用两层结构，MPU控制大规模时序逻辑电路（FPGA芯片），由FPGA读入路口特征数据进行处理，然后输出灯色控制信号。MPU的控制正常时，FPGA听从MPU的相序和步伐指定，而一旦MPU出现异常，则立即脱离MPU进入安全模式，自主决定相序和步伐，平滑输出灯色控制信号。

　　三、对工作模式的分类：工作模式的降级优先顺序是，远程模式（执行上位机信号方案）、多时段模式（执行本地机信号方案）、安全模式（诸如MPU异常、时钟故障时）、异常闪光模式（绿冲突时，主道黄闪/次道红闪）。无论信号机工作在远程模式，还是多时段模式，信号方案的核心信息都一样：相序、周期、相位差、绿信比。在信号周期开始前，就要确定信号方案，否则就要降级。作为周期方案控制的信号机，信号方案是战略规划。在这基础上，允许感应控制，此为战术微调，感应控制是叠加在远程控制上或多时段控制之上的，因此，它只是附加控制，不归到上述的工作模式之中。只有在远程模式或多时段模式时，才能实施，与绿波协调控制共存是常态。但如果信号机降级到安全模式之下，就立即停止感应。它可能在远程控制时不实施，而在多时段控制时实施；也可能在远程控制时实施，而在多时段控制时不实施，因此，它与远程模式或多时段模式不存在降级关系。

　　四、相位差追随方式的规范：信号机中的绿波协调方案与单点控制方案采用的是同一个数据格式，相位差的指定采用基于基准时间的绝对相位差。当方案中的相位差无具体指定时（其值=0xFF），视为单点控制。当方案中的相位差有具体指定时（其值=0～254），视为协调控制。多时段控制时，以方案切换时间为基准时间，每周相位差的追随量规范为：正向不超过20%，负向不超过5%，以最短时间为目标自主决定追随方向，最多4个周期完成相位差追随。远程集中控制时，指令中含有基准时间，每周相位差的追随量由指令指定：有正向最大25%，或有正向或负向最大12.5%。追随方向有自主判断和定向指定，比多时段控制灵活快捷。

　　综合上述的三点与四点，可以看出，信号机仅有工作方式之分，而没有单点控制信号机、协调控制信号机和感应控制信号机的机型之分。

　　注：当一个信号系统与信号机属于不同厂商时，信号机在协调控制时，其相位差的追随方式必须有统一规范。

　　二、建议

　　制定国标的目的在于规范行业所用的通用技术，把行业各方的技术研发力量指引到一个方向上，以促进行业技术的快速发展。因此，所定的行业标准应该是开放性的，通用技术的规范内容不仅要力求科学、简洁、灵活，还应预留一些自由空间（协议中留预备字节）让行业各方去发挥自己的技术特色。

　　通用技术要求中的5.2表1的“功能配置表”和5.5中的“控制方式选择”一项，其内容还可以再完善和明确化。跟信号机有多种降级关系的工作模式一样，系统集中控制下的路口也需要有多种降级关系的控制模式。按优先级应该归结如下：1）远程紧急手动；2）手动干预；3）定时干预；4）自动优化；5）系统多时段。这些控制模式应由系统自动选择，除了远程紧急手动，其它4种控制模式（2、3、4、5）都是通过给终端信号机发送信号方案实现的，因此，这些指令应采用统一的数据格式。另外，中心控制台也可以通过人工干预让系统放弃对某一子区所有路口或某路口的集中控制，让相关的信号机从远程模式降级到自身的多时段模式。

　　这些降级关系的工作模式的实用性如下：如某些意外事故发生，中心控制台的人员可以立即对某路口进行远程手动控制，即紧急远程手动干预（如：紧急黄闪、紧急全红、远程手动步进、步伐保持），是即时、最优先的。又如，若某干线道路处于过饱和堵塞状态了，需人工调用专家信号方案，即手动干预。在无紧急远程手动干预的情况下，这个手动干预应在下一个信号周期开始被付诸执行。再如，若某路段有高中小学校，上放学期间都要进入拥堵状态，那么在不存在前者之一的情况下，系统应自动调用预置的信号方案，即定时干预。只要到了时间点，信号周期一开始就应该付诸执行。在不存在前者之一的情况下，如果系统有自动方案优化功能，且检测器数据均为正常，则进入自动优化控制（自适应控制）。如果，系统没有自动方案优化功能的，或有自动方案优化功能但因检测器故障导致无法优化，则根据系统侧的方案切换时刻表选择系统侧的信号方案，让该路口进入系统多时段模式。

　　要让系统有效运行，需要很多不同的数据做支撑，但无论有多少数据，均可归纳为4类数据：1）上位系统参数；2）终端信号机参数；3）上位系统下达的实时指令数据；4）信号机上传的实时状态信息。其中，上位系统参数是指让上位机正常运行需要的参数。如：路网配置参数，手动干预/定时干预/自动优化/系统多时段控制所需的配置参数或方案等等。终端信号机参数则是指路口信号机自身运行所需的各类配置参数，这两者应该明确区分。

　　若在一个系统下，可以运行不同厂商的信号机，实际上只要针对上述3）类和4）类的数据格式做统一规范就行了。而针对2）类参数，比较好的办法是：对各类参数进行编码规范，但无需对参数格式做统一规范，以避免造成对信号机功能的束缚。基于不同厂商各有自己的信号机参数设置软件，用户可以利用它设置参数，然后保存在系统指定的地方。这样，系统向路口传送信号机参数时，仅把其作为纯粹的文件发送。信号机接收后，根据文件类型和该型参数的自家格式进行解释，检验通过后保存在信号机内。对1）类数据也无需做过多的硬性规范，应该作为指导性的，并多留些预备字节，供各区域系统的厂家自由发挥，等待行业成熟并有了共识后，再做正式规范。

　　通用技术要求中的“5.6.2控制参数设置”中，有单点控制参数和感应控制参数。这两个参数应该由信号机自身持有。系统要某个路口进行单点控制，只要把远程信号方案中的相位差置为0xFF（集中控制下的单点控制）、或发送脱机指令（本地控制下的单点控制）即可。系统要某个路口进行某类感应控制（泛指各类根据检测器信息改变原有控制途径的），只要在远程信号方案中指定某类感应即可，信号机根据自身的感应参数实施，因此此类参数应归类于信号机参数。系统进行自适应控制的参数很多，如：有关子区的、有关路段的、有关关键路口的、有关普通路口的参数等等，最好开放给各厂商自行设计。

　　针对上述3）类、4）类的数据类型和数据格式，则对应通用技术要求中5.9的“运行状态检测”。考虑到一个上位系统多则管辖200多个路口这一因素，服务器处理通信的时间和次数要力求短和少，协议格式既要精简，又要满足系统实时控制的需求。基于这些考虑，通用技术要求中5.9“运行状态检测”中的信息种类和每类信息的内容还需要扩充。

　　建议上位系统下达信号机的远程指令采用4条指令：1）紧急手动指令；2）远程信号方案；3）时钟校准指令；4）5分钟检测器情报请求。

　　建议信号机上传给上位系统的数据采用4条报文：1）信号机运行状况；2）周期信号执行情报；3）时钟校准应答；4）5分钟检测器情报数据。

　　建议要求信号机每秒钟主动上传信号机运行状况，每个信号周期结束时，主动上传周期信号执行情报，或在系统请求周期信号执行情报（通信恢复后）的情况下，上传通信中断前的周期信号执行情报。要求信号机在收到系统时钟校准指令（GPS故障）时，上传时钟校准应答。要求信号机在收到系统5分钟检测器情报请求时，上传5分钟检测器情报数据。针对检测器数据，之所以不建议信号机采用5分钟整点主动上传的方式，是考虑信号机有出现时钟异常和时间偏差的可能，所以由上位系统5分钟整点统一发出请求较为妥当。

　　建议要求每当信号机接收到上位系统下达的上述指令时，需对指令内容进行检验，无论正确与否都需要反馈检验结果，并把这个结果信息反映在每秒主动上传的信号机运行状况中，连续反映3次即可。

　　以下是上述各类数据的主要内容和格式的建议，以共参考。

　　1、紧急手动指令

　　1）不定期指令编码（建议占用1字节：13～15）

　　2）指令识别（建议占用1字节，紧急手动内容用比特位识别：紧急黄闪、紧急全红、远程手动步进、步伐保持、脱机/联机，共5位）

　　3）指定步伐（建议占用2字节，远程手动步进或禁止步伐前进时有效，第1字节是指定步伐，第2字节作为预备。若是双环相序信号机，第1字节则用于指定N环步伐，第2字节用于指定S环步伐）。

　　4）预留4个字节（留给区域机厂商对自家产信号机做特色控制）

　　注：步伐保持常用于警卫路线控制

　　2、远程信号方案

　　1）定期指令编码（1～12：利用时钟1个小时中的5分钟区间号识别定周期指令）

　　2）相位差基准时间（时：分：秒）

　　3）相序（编号）

　　4）周期（秒）

　　5）相位差（秒）

　　6）绿信比（秒或%）

　　7）周期内相位差的最大追随量（%）

　　8）追随方向（编码：正向指定、负向指定、或由信号机自由判断方向）

　　9）感应指定（比特位指定感应类型、允许复合感应，如：车辆间距感应、公交优先感应、相位请求感应、可变车道导向感应等）

　　10）感应时各相位的最大延长时间（秒）

　　11）感应时各相位的最大缩短时间（秒）。

　　12）预留至少64字节（留给区域机厂商对自家产信号机做特色控制）

　　注：相位差的指定，建议用1字节，其值为0xFF时，表示不做协调控制。双环相序信号机对绿信比、感应时各相位的最大延长时间、感应时各相位的最大缩短时间，都需要双倍的数据空间。这可以在格式中做出正式规范，也可让其包含在预留字节中。

　　3、周期信号执行情报

　　1）执行远程指令编码（1～12，上位机用以识别执行的远程指令是否正确）

　　2）周期开始时刻（时：分：秒）

　　3）信号机工作模式

　　4）发生的故障（用比特位指定，可表示复数个故障。如：导致异常黄闪的各类原因）

　　5）原信号方案的预定周期（秒）

　　6）实际执行的周期时间（秒）

　　7）本周追随的相位差（秒）

　　8）禁止步伐前进时停止的步伐

　　9）6个相位感应导致的变动时间（秒，单环信号机或双环相序信号机N环所用）

　　10）附加6个相位感应导致的变动时间（秒，双环相序信号机S环所用）

　　11）24个步伐的执行时间（秒，单环信号机或双环相序信号机N环所用）

　　12）附加24个步伐的执行时间（秒，预备或双环相序信号机S环所用）

　　13）128个检测器装备定义（16个字节，用比特位定义，比特位置作为检测器编号）

　　14）本周期检测器情报（每个检测器信息用4个字节，装备多少个检测器就顺序送多少个数据，最大512字节。检测器信息：占有时间2字节、车流量1字节，及预备1字节）

　　15）预留64字节（作为区域机厂商对自家信号机传送特殊信息）

　　注：周期信号执行情报中的检测器情报是每个信号周期的数据，是应对信号方案自动优化计算需求的，而5分钟检测器情报只能作为报表绘图所用。两者不可混淆，否则计算的自适应控制方案，会有较大的波动性。因为在同等交通流情况下，前5分钟和后5分钟所包含的周期数可能不同，导致检测到的5分钟交通流数据可能不同，据此计算得来的信号方案也就产生较大差别了。

　　另，这里所建议的协议是认定一个相序最多安排6个相位、24个步伐。

　　4、信号机运行状况

　　1）当前执行的步伐（双环相序信号机时指N环）

　　2）预备执行的步伐（预备或双环相序时指S环）

　　3）执行的相序方案（编号）

　　4）指令编码和接收确认信息

　　5）控制状态：表示是否处于终端手动操作中、是否处于紧急远程手动操作中、是否处于远程方案控制中、是否处于协调同步中、是否处于绿灯状态、是否处于禁止步伐前进中、是否处于黄闪中。（这些状态可复数存在，建议用比特位表示）

　　6）信号机故障信息：时钟异常、GPS异常、导致黄闪的异常等。（这些状态可复数存在，建议用比特位表示）