城轨云的前世今生（上）
最近看到一位求职者用如下简洁的方式描述自己的工作履历，作者也尝试了一下这种方式，以方便读者对文中相关时间节点的理解。
我的履历
我的主要工作
2016年，或可以被称为“城轨云元年”，在这一年，城轨云第一次以展会展出的形式进入公众视野。至2021年，已有温州、呼和浩特、清远、深圳、郑州、上海和太原（排名不分先后）等多个城市已经建设和正在建设基于城轨云的城轨运营控制和信息化系统。
本文将与各位读者一起回顾城轨云的发展历程，并对未来的发展进行展望。
【促动期】
按照技术成熟度曲线（The Hype Cycle）的定义，2018年以前，可以看作是城轨云的促动期。
城轨云最早可以追溯到笔者在C公司工作期间，CBTC系统的仿真和TIAS的研发，对城轨云的诞生起到了促进作用。
C公司拥有一套完整的CBTC系统仿真测试平台，但那时还没有城轨云的概念，整套系统由多台工控机构成，通常一条线路的仿真测试，仅使用1至2套成品设备（如ZC、VOBC、联锁、DSU等），其余设备则通过部署在工控机中的仿真软件实现。
每次测试新线过程中，仿真环境的配置，包括工控机操作系统安装，网络配置，仿真软件的部署等工作消耗了大量时间。
2013年末期，随着TIAS（一种信号与综合监控集成的列车运行控制系统）的研发，采用“云”方案第一次被提上议事日程，当时的目标，是开发一种故障转移集群，同时满足综合监控系统监控点大规模接入和信号系统对安全性的需求。但在当时，并没有确定具体的技术路线。
2014年末，笔者加入了A公司，主要承担CBTC系统的仿真测试工作。在A公司，笔者见到了城轨云的雏形。
与C公司不同，A公司的测试平台完全采用软件仿真的形式。
仿真软件由ADA语言编写的系统内核（代码与成品设备相同）和Python语言编写的接口程序（以适应在PC上部署）构成。
仿真系统硬件则包含多台基于AMD opteron处理器的SMP服务器和基于Citrix的虚拟化平台。
系统中每台设备（CC、ZC、TOD、联锁等）相应的仿真软件，均可用虚拟机承载，系统间通信通过Citrix XenServer平台内置的SDN系统实现。
这套基于虚拟化的仿真平台可以说是城轨云的雏形，但当时业内并未对此形成一致认识。
2016年下半年开始，城轨云的发展进入了快车道。
随着TIAS的研发完成，城轨云第一次走入公众视野，2016年9月至10月间，分别在上海举办的华为HC2016及在德国举办的Innotrans 2016上展出。
城轨云在华为HC 2016首次展出
城轨云在Innotrans 2016上展出
2017至2018年间，业界就城轨云解决方案，与业主、设计院、中国城市轨道交通协会等进行了广泛的沟通，就业主关心的安全性（safety和cyber- security）、可靠性、投资和运营成本、运营和维护模式等问题进行了深入的交流，就城市轨道交通运营系统的云化达成了广泛的共识。中国城市轨道交通协会开始主持编写相关技术标准工作，并确定将呼和浩特1/2号线作为城轨云应用示范工程。
与此同时，以华为为代表的云平台厂商，与地铁运营控制系统厂商（信号、综合监控、PIS、CCTV等）进行了广泛深入的联合测试，累计有超过30家厂商参加了多轮联合测试，基本扫清了主要系统在IaaS平台中部署的技术障碍。
- 用户评论
