引子
2017年12月30日，中国内地首条拥有全部自主知识产权的全自动驾驶的“北京地铁燕房线”投入试运营，该线路符合EN62267/62290定义的自动化最高等级-- GoA 4级（Unattended Train Operation， UTO），其关键部件均为国产并实现了全自动运行（FAO， Fully Automated Operation），降低了人为失误风险的同时，更提高了安全性和效率，进一步提升了出行质量和乘坐体验，我国进入了完全自主知识产权的轨道交通全自动运行的新时期。
北京地铁燕房线（来源自网络配图）
全自动驾驶在中国
目前，全世界有62条线路采用了GoA 4级（UTO）的全自动运行技术，分布在19个国家的41个城市。
世界全自动运行线路统计（源自2018年1月3日UITP的统计）
其中，在中国有广州、上海4个城市的6条城市地铁/轻轨线路采用了UTO技术：
1，广州珠江新城地下空间旅客输送系统APM线。采用庞巴迪CX100胶轮自动导向车辆，于2010年11月8日开通运营。
2，上海地铁10号线。是中国首条采用UTO技术的重载城市地铁线路，项目一期建设了31座车站，二期将延伸建设6个车站，设有两座互为热备的调度控制中心，于2010年11月28日开通，日均客流60万人次。上海10号线开通时并没有启用UTO模式，从2017年3月9日起，部分车辆已经在UTO模式下运行。
3，香港地铁迪斯尼线。香港地铁网络中的第一条UTO线路，2005年8月投入使用。
4，香港地铁南岛线。香港地铁网络中的第二条UTO线路，2016年12月投入使用。
5，北京地铁燕房线。中国内地首条自行研发的UTO线路，2017年12月投入运营，初期在GoA 3级下运行，将来切换至GoA 4级运行。
6，上海地铁浦江线。采用庞巴迪APM300胶轮导向车辆，将于2018年第一季度开通运营。
另外，北京机场和香港机场航站楼之间的APM摆渡线均是全自动无人驾驶的。
传统模式下的综合监控系统ISCS
从2000年左右开始，中国内地地铁的自动化系统逐步从分列式监控系统向综合监控系统（ISCS）发展，当时的地铁公司、设计单位和集成商进行了很长时间的争论，技术焦点主要包括：
- 采用分列系统还是综合监控？综合监控的优点是什么？是否值得投资？
- 集成和互联子系统，哪些集成，哪些互联？接口的协议、方式是什么？
- 综合监控应实现哪些功能？联动功能的自由定义能否实现？能够实现辅助决策？
- 采用什么样的综合监控系统软件？系统软件的数据流必须符合哪些特定的需求？
- 采用什么样的操作系统？Windows和UNIX哪个更合适？
- 采用什么样的硬件？服务器采用RISC架构还是CISC架构？硬前置还是软前置？
这个阶段在2010年左右（十一五）结束，彼时的综合监控系统已经发展成为一个独立的、标准的设备系统（专业），与车辆、信号、通信、供电、PSD等成为线路开通运营的关键系统之一。综合监控一般集成供电、机电、门禁、PSD、FAS、PIS、PA、CCTV等系统，与信号、车辆、售检票等系统互连。典型的综合监控系统是一个分层分布式的、热备冗余的实时数据采集和监控（SCADA）系统，系统软件的架构及数据流处理机制应能在保证实时性、安全性和可用性的基础上，适应分期开通、主备OCC倒切、多线拆分等多种操作需求。
ISCS典型系统架构（NARI）
综合监控系统为地铁运营公司的“两级管理、三级控制”、线网中心提供了非常有效的调度管理工具，极大地提高了调度管理的效率，联动功能的大量使用保证了应急调度的可靠性，提升了安全性。
行车指挥综合自动化系统TIAS
随着地铁线路的增多以及线网调度指挥中心的投入使用，地铁运营对设备系统的调控在广度和深度两个维度上的需求不断增加，主要是源于各类突发情况的增多，需要实现的联动功能也日益复杂。从2011年左右开始，北京地铁开始尝试更大范围、更深层次的系统集成，以满足调度员对跨专业调度效率和安全性越来越高的需求。经过一段时间的调研，北京地铁6号线首次建设了“以行车指挥为核心的综合自动化系统（Train Integrated Automated System， TIAS）”，在传统综合监控的基础上，将信号的ATS与综合监控ISCS进行集成，为线网、线路中央调度员和车站值班员提供统一的监控平台和操作终端，实现更高效、更安全的调度管理。
北京地铁6号线TIAS系统架构
北京地铁6号线的TIAS基于ISCS平台（南瑞），保持了信号ATS服务端数据库和综合监控服务端数据库的相对独立性（但是，两套实时数据库运行在同一套物理服务器上），将ATS的HMI端集成嵌入到ISCS的客户端中，ATS HMI通过ISCS的平台总线实现与ATS服务端数据库的交互和通讯，并接受ISCS的系统管理，从而实现了信号与综合监控系统调度操作的统一。虽然北京地铁6号线不是全自动驾驶（UTO），但是在自动化系统的集成方面进行了有效的尝试。
北京地铁6号线TIAS软件集成示意图
全自动驾驶模式下的TIAS
北京地铁燕房线在EN62267/62290定义的GoA4级（即UTO）的基础上，利用TIAS这个综合性的实时数据平台采集了包括车辆、信号、通信、供电、机电、售检票、安全门等所有设备系统的实时信息，实现了场景化的自动联动功能，根据各类资料显示，燕房线共设计了约41个运行场景，包括18个正常场景和23个异常场景。
燕房线的运行场景（来源：互联网资料）
燕房线TIAS与北京6号线TIAS在ATS和ISCS数据的集成上有一些区别，或者说有一些进步。燕房线ATS服务端数据库和综合监控服务端数据库依然保持了独立性，并运行在两组不同的物理服务器上，但是，TIAS的客户端完全由ISCS提供（和利时），不再像6号线那样由ISCS客户端将ATS的客户端以控件方式集成。这是软件机制上优化的一小步，却是整个城轨系统集成行业的一大步，基本上指明了符合中国国情的“大综控”未来的技术道路。
北京地铁燕房线TIAS软件集成示意图
新时期新一代综合监控系统的发展趋势
目前，已明确在十三五期间规划建设全自动运行的线路已经超过了16条，350公里。主要分布在北京、上海、广州、深圳、宁波、苏州、南京、成都、天津等城市，有很大一部分线路是新出现的“市郊线”（采用交流牵引机车，速度更快）。另外，还有大量的有轨电车、单轨、云轨（比亚迪）等中小运量线路也大量全部采用全自动运行方式，其配置的"智能化行车调度指挥系统"（Train Integrated Dispatching System, TIDS）与地铁的TIAS内涵一致。
随着建设线路的不断增加，将来的运营和维保将会是一项严峻的挑战，由于轨道交通的公益性质，对人身安全、准点、成本控制等方面有较强的敏感性，笔者认为，现在的综合监控系统ISCS未来会被行车指挥综合自动化系统TIAS完全取代，且服务于运营调度的综合自动化系统（TIAS或TIDS）将会在如下几个方面快速发展：
1，未来的TIAS/TIDS系统将面临新一轮的技术争论：即系统软件的核心是ATS还是ISCS？一方是传统的信号系统厂家；另一方则是原来的综合监控厂商。笔者判断，这一轮技术争论的焦点在于“什么样的系统软件适合做TIAS平台？”很多论点喜欢从SIL安全完整性、功能复杂性方面论证，试图表明能够处理SIL2级别的行车管理系统更适合做TIAS平台；也有一些论点从数据处理的兼容性、联动功能的灵活性方面论证综合监控软件的特性更加符合TIAS/TIDS的需求，不一而足。其实，适合的才是最好的！谁最适合全自动运行方式下的调度管理的需求，谁就是最合适的软件平台。
2，与云计算的融合。这个议题实际上可以单独成为一个讨论的专题，云计算应用的意义并不仅仅在TIAS/TIDS，而在于将彻底改变城市轨道交通自动化和信息化的基础计算设施，降低业主总体拥有成本，提高可靠性，也可以方便地融入各项新技术。IaaS很快将成为与隧道、建筑等一样的重要基础设施，所有的计算机系统都会构建在云计算基础设施上。在自动化系统范畴里，部分PaaS层和全部SaaS层的实现应该由TIAS/TIDS系统集成商完成，这对现有的平台机制产生深刻的影响，需要重新评估各项传统功能的实现方式，比如：可以利用基于容器的技术重构TIAS/TIDS的SOA架构，打散传统的以车站为单元、业务与硬件和虚拟机捆绑的部署方式，将目前的各个专业功能解耦到微服务颗粒，将云平台的运行状态纳管到TIAS/TIDS中的NMS功能中来，等等。在信息化范畴里，云平台的优势会得到更大的应用和发挥，如：图像数据的存储和分析，互联网+乘客服务的广泛应用（目前是各地的刷码过闸机，最终将是无闸机的自动进站识别），各类物联网技术用于状态检修和在线监测时基于云平台的数据挖掘和分析，等等。
TIAS/TIDS的微服务架构（NARI）
3，在操作功能上，未来的TIAS/TIDS必须兼顾路网和线路调度的多级一体化的操作需求，同时，由于车站级各岗位的合并，将来站级运营人员的主要任务是服务乘客和在异常场景下引导疏散客流，车站级值班员的操作功能将大大弱化，大量的设备操控、电话、广播等操作将全部集中到站级人员随身携带的移动终端上。站级TIAS/TIDA系统的主要任务将是如何进行全数据信息的接入、采集和预处理，为中心和线网层提供基础数据。而在中央级，未来的TIAS/TIDS则需要基于大数据挖掘为线路和线网运营、乘客服务提供更多更好的增值服务。
TIAS/TIDS的大数据实现架构（NARI）
4，TIAS/TIDS的信息安全解决方案。虽然业内已经行程普遍共识要求综合监控系统应符合工业控制系统安全等保三级的要求，伴随全面深度集成系统的应用，地铁运营企业应该从顶层开始整体规划设计本城市轨道交通线网的信息安全等级保护体系。比较务实的实施方案是一个安全管理中心支持下的计算环境、区域边界、通信网络三重防御多级互联的技术框架。
安全管理中心支持下的计算环境、区域边界、通信网络三重防御多级互联的技术框架
应该在这个框架下来详细考虑TIAS/TIDS的信息安全措施，而不是像现在将防火墙、网闸之类的设备简单堆砌。特别是安全区域的划分、各区域之间的通信加密是未来的重点，有点可惜的是此次的《城市轨道交通综合监控系统技术规范》国标的修编中没有将这部分内容进行更为详细的定义。
5，未来车站级的综合后备盘（Integrated Backup Panel，IBP）将不断增加系统故障后的应急操作功能，特别是异常场景下的后备操作手段。这是与上述第3点相互匹配的。如果在基于云计算平台的TIAS/TIDS中心级故障时，降级模式下各车站的操作将主要依靠IBP盘，对于有些应急设备较多的换乘站，那么电子触摸屏将有很大可能在IBP上广泛应用。
网友评论