根据技术成熟度曲线（The Hype Cycle），当前城轨云正处在期望的峰值（Peak of Inflated Expectations）期，随着城轨云应用范围的逐渐扩大，特别是线网级城轨云平台的建设，基于城轨云的线网级运营指挥系统的复杂度将空前的提高，在系统的设计和运营领域面临着极大的挑战，需要更深入的研究和实践，由此可以断定，城轨云即将进入幻灭和低谷期（Trough of Disillusionment），能否跨过这一时期，在不断实践中解决系统中存在的问题，找到切实可行的建设和运营模式，是未来城轨云发展的关键。必须要指出的是，这是一个需要长期实践的过程，不可能通过一两个示范项目，一套技术规范完美的解决。而需要大量具备先进工业IT知识的技术人员（轨道交通企业的读者可以审视一下自己所在的企业是否具备），充实到系统设计、建设和运营过程中，通过对系统的不断迭代实现。

本文将分析城轨云系统中存在的部分矛盾，目的在于抛砖引玉，如有不妥，也欢迎各位读者批评指正。

（1）ATS在云中部署

目前落地的城轨云项目中，ATS均采用裸金属服务器（Bare Metal Server，BMS）部署，裸金属服务器相对于虚拟机，物理服务器资源（计算、存储及网络）直接由操作系统调度而不经过被称为Hypervisor的虚拟化层，数据流亦不经过虚拟交换机（VSW）。裸金属服务器和虚拟机的逻辑结构参见图1。

图1 裸金属服务器（左）和虚拟机（右）

目前对于引入Hypervisor对安全性（Safety）的影响，尚未有过系统性分析，主要原因或许是Hypervisor过于复杂，目前对其故障模式及其影响尚缺乏了解。即使Hypervisor为开源组件，但其代码量过大，进行系统分析存在难度，同时开源Hypervisor本身不是为安全系统所设计。

与之类似的问题还有桌面云的使用，由于ATS系统操作员工作通常兼做联锁系统上位机，存在诸如取消进路、人工解锁和强扳道岔等安全相关操作。如果使用桌面云作为操作员工作站，则上述安全命令需经过远程桌面协议由瘦客户机到达桌面云中的操作员工作站，而远程桌面协议是否能够保证安全命令的下达，目前尚无定论。因此，不建议使用桌面云作为ATS操作员工作站。如图2所示。

图2 桌面云作为ATS操作员工作站

（2）安全域的划分与边界防护

按照中国城市轨道交通协会推荐标准T/CAMET 11005-2020《城市轨道交通云平台网络安全技术规范》（以下简称规范11005）的要求，城轨云平台被划分为运维管理、安全生产、内部服务和外部服务四个基本安全域，同时对不同安全域间的边界保护做了严格规定。如图3所示。

图3 城轨云平台安全架构

该架构在实际应用中存在一些问题，首先，一些安全措施，诸如在外部服务网和内部服务网之间采用数据摆渡技术，是难以实现的，原因在于外部服务网和和内部管理网以及安全生产网间，存在非常多的实时业务，如移动办公，互联网票务等。同理，在安全生产网与信号专网之间，采用数据摆渡技术的问题也存在同样的疑问，原因在于信号智能运维的实时数据流量如何处理。

其次，在安全生产网和外部服务网之间，不可避免的会出现穿透内部服务网的流量，以互联网票务（IAFC）与自动售检票（AFC）系统间的流量以及内部和外部ACC之间的流量为主，这些流量连续穿过两道边界防护，略显繁琐。

再次，该架构忽略了智能运维系统及配套的大数据平台的部署需求。智能运维及配套的大数据平台应部署在哪个安全域中，如何与其他安全域通信成为必须要考虑的问题。

综上，作者设计了一种技术架构，试图解决上述问题，如图4所示，也请各位读者批评指正。

图4 城轨云改进的安全架构示意图

说明：

1. 运维管理网未画出。

2. 在内部服务网部署运维大数据平台和智能运维系统。其中智能运维和运维大数据宜独立划设3级安全子域。

   流量（1）（安全生产网与内部服务网间）主要为安全生产网内工控系统实时及历史数据，用于智能运维，可采用单向隔离或数据摆渡技术。

   
   

3. 内部服务网部署企业管理大数据及OA。

   流量（2）（内部服务网与外部服务网间）主要为移动办公和智能运维（公网移动运维，可借助iOA，如企业微信实现）。

4. 外部服务网部署互联网票务（iAFC），乘客服务（iPIS）和移动办公应用（iOA）。

   流量（3）（安全生产网与外部服务网间），主要包括互联网票务（双向）、内外网间清分清算业务（双向）和iPIS和PIS之间的通信业务（单向）。

   其中，互联网票务及内外网间清分清算业务，由于涉及外部服务网与内部服务网间双向通信，宜单独划设3级安全子域。

5. 全网在外部服务网设置唯一外网出口，并进行边界防护
   

最后，提出作者的一点担忧，也就是随着AFC系统互联网支付的发展，不可避免的使得iAFC系统数据流量穿越到安全生产网AFC系统内，使用二维码的iAFC系统与使用NFC技术的银联闪付（iAFC）、储值卡（AFC）、单程票（AFC）业务均在闸机内的同一台工控机上承载，从而形成了实质的业务耦合，是目前AFC系统现在信息安全方面面临的新挑战，目前尚未有明确的防护方案。

（3）大数据平台及其应用

在一些新闻报道中，经常谈及“XX项目采用了云、大数据、物联网等先进技术”云云，似乎云和大数据二者是一对共栖共生的技术，但实际上，在城轨云平台中，二者并无直接联系。云，通常指一种IT系统的交付和服务模式，而大数据，通常指一种海量数据处理方法及配套组件。在城轨云平台中，主流的基于Hadoop的大数据平台及其配套的存储，均采用物理机以及独立存储集群部署。即使没有基于虚拟化技术的IaaS云平台，也可以独立部署大数据平台。

当前城轨领域对于大数据技术的应用，尚没有显现出应有的效果，分析其原因，主要在以下几个方面。

第一，对于数据的建模是一个长期的过程，首先必须积累足够的数据，再运用适当的算法进行分析，才能够发现其中的规律，这一过程所消耗的时间，通常以年甚至更长时间尺度计算。当前很多项目中，由于对数据分析投入不足和数据积累不够，并没有达到预期效果。

第二，对于数据的分析需要相当的专业知识，当前数据平台厂商及数据智能厂商往往不是设备系统厂商，对于需要分析的系统，不具备相关专业知识，对数据语义理解不够，难以挖掘出有价值的结论。

第三，很多数据分析项目的最终成果，往往不是数据应用，而仅仅是分析结论。例如，对某一部件修程修制的改进分析，最后的结论，仅仅把原来3个月的维修周期延长至6个月而已。

第四，由于上述问题，当前大数据项目，往往存在重数据存储，轻数据应用。很多项目还停留在数据可视化的较浅层面，这类项目只是让数据换一个地方沉睡而已，实际应用效果有限。也许部分读者会说，先建设数据平台，再逐渐增加应用，但扪心自问，数据平台建设完毕以后，又有多少人打算继续投入数据应用和算法建设？大数据平台的建设，是否会重蹈当年数据仓库建设的覆辙，是一个值得重视的问题。

第五，在各系统已经形成条块分割的专业壁垒的情况下，难以做到数据应收尽收，各专业的数据缺乏碰撞和交叉验证，增加了规律发现的难度。

综上所述，大数据应用的建设，是一个困难的过程，必须持续投入，长期积累，广泛汲取数据智能厂商和设备厂商的系统知识，做到所需数据应收尽收，做好打持久战的准备，才能有所收获。

（4）数据库的部署

当前城轨云平台中的数据库系统，如ATS、ISCS的历史数据库、AFC系统的交易和历史数据库等，通常均采用国外产品，如DB2及Oracle等。同时，数据库系统多为物理机部署（传统RDBMS通常不支持虚拟化部署），且专系统专用，不仅成本高而且维护较为复杂。

近年来，随着互联网票务业务的发展，MySQL等开源数据库产品逐步获得了应用。同时，以腾讯TDSQL为代表的，基于开源版本的商业化数据库产品，经过金融级系统应用的挑战，已经逐步成熟起来，这类系统具备支持集群化纵向扩展和多副本的特点，可满足未来线网级应用的扩展需求，可以作为未来城轨云平台中，自主化数据库的替代产品。

（5）云平台的管理及运维

云平台的运维及管理，有可能成为未来困扰采用城轨云平台的城轨运营企业的主要问题。首先，虽然云平台厂商极力宣传，采用云平台，通过统一运维系统，可以做到状态可视化，降低运维难度，节省运维成本。但实际上，云平台运维具有相对陡峭的学习曲线，需要对云平台基础知识有深入的了解，目前多数城轨运营企业，不仅不具备足够的技术力量，甚至没有相应的人员组织。

必须指出的是，除了单线路单专业的云，可以由对应专业的人员代为维护外，线路级多专业云和线网级云，必须设立专门的云平台运维组织，统一协调和管控云平台的使用和维护，不能让云上各系统运维人员随意对云平台进行操作。同时，尽管云平台采用分层解耦运维的维护体制，但云平台专业人员和各专业系统应用运维人员，仍需要互相学习。在系统发生故障时，如何判别问题出处是云平台还是专业系统，是二者必须面临的问题，需要经过长期的磨合和经验总结才可能做到快速准确，避免推诿扯皮。

本文简要分析了城轨云当前以及未来一段时间已经或可能面临的问题，由于笔者对于城轨云的建设、运营和维护的各个方面的经验所限，文中难免有疏漏之处，文中提及的问题，也许各位读者心中已有解决办法，欢迎您的批评与指正。

（全文完）