01概述
截至2019年末，中国（含港澳台）共有43个城市建设了地铁系统，其中开通线路10条以上的城市6个（上海、北京、广州、南京、重庆、香港），开通里程100km以上的城市达19个。多个城市已经或即将逐步转入线网化运营阶段。
但是，长期以来按线路和专业划分的建设模式，造成线路、专业条块分割，各系统互通、联动困难，无法满足线网化运营的需求。近年来，IT技术有了长足的进步，以云计算、大数据、物联网为代表的新一代IT技术，为企业的“数字化转型”创造了条件。但轨道交通企业对IT系统，特别是生产IT系统的技术能力不足，通常只具备运维能力，而不具备架构设计能力的现实，使企业在数字化转型探索过程中走了不少弯路。同时由于数字化转型项目周期长、投入大，由于一些投资策略方面的原因，目前业内鲜有成功案例。本文介绍了城轨行业数字化转型的基本方法，意图抛砖引玉，文中不当之处，欢迎读者批评指正。什么是数字化转型，虽然很难用一句话说清楚，但也并非是一门高深的学问。简单的说，数字化转型，可以从下列几个方面进行规划。
1. 确定目标
数字化转型，就是利用先进的IT技术，整合公司的IT系统，构建适应当前和未来公司运营的支撑系统。对于轨道交通企业而言，数字化转型，就是构建适应线网运营条件下的公司级运营支撑系统。这个系统不是过去单线路、单专业系统的简单堆叠，而是各线路各专业系统的高度融合，除保证运营安全外，还具有简单易用、高自动化程度、高可维护性、高可扩展性、低建设和运维成本以及良好的乘客体验。同时，该系统也不是各类先进IT技术的堆叠。很多所谓的“数字化转型”项目中过分追求技术的先进性，我们经常听到，某某项目要采用云计算、大数据、物联网等先进技术，要构建数据中台，业务中台云云。但却忘记了，业务需求才是才是数字化转型的根本，此类项目的架构设计人员很少考虑，采用这些技术，构建中台，是为了支撑什么样的业务，以及为什么要采用这样的技术等等问题。这里必须要强调的是，脱离业务，空谈采用某某技术，以及构建中台，是难以达到预期效果的。业务架构是指企业运营过程中，需要处理的事务的总和。例如，轨道交通公司的日常事务包括，行车组织、乘客服务、设备运维和日常办公等。业务架构和公司组织架构紧密相关，因为每件事务，都至少由一个组织或部门负责，也可以是由不同的组织、部门依据一定的流程协作完成的。通常在数字化转型过程中，都或多或少的涉及到业务架构重组（流程变革，例如由传统系统转向全自动运行系统，改变了原有调度班组构成），当现有组织架构无法适应变革后的业务架构时，就需要对组织架构进行调整。而组织架构调整，有时会成为数字化转型的主要阻力，必须仔细考虑。在业务架构中，有一部分是为企业直接创造价值的，称为“价值流”，是企业赖以生存的基础，数字化转型过程中，必须着重考虑这一部分业务架构。完成业务架构梳理后，需要依据业务架构，制定支撑业务架构的能力列表，作为后续工作的输入。例如，支撑行车组织业务，需要的能力是客流分析与预测，运行图和人力排班计划编制等业务能力。再次强调，业务架构是数字化转型的基础，在数字化转型项目中，必须首先完成业务架构的设计，否则后续工作都将成为无本之木，无根之水。目前有一种很不好的倾向，架构设计人员在不了解业务的情况下，就盲目使用通用技术架构套用，极有可能导致技术架构与业务架构无法互相适应。例如，依据行车组织、乘客服务、设备运维日常办公的业务架构。将这个公司IT系统分解为下列应用系统：（1）行车调度系统：包括信号、综合监控和客流分析仿真系统（2）乘客服务系统：包括PIS、AFC、客服呼叫中心等。（3）设备运维系统：包括机电系统综合运维、通信系统综合运维、车辆综合运维和备品备件供应链管理体系等。其中，每个子系统又需要根据具体的能力需求明确系统需求、软硬件需求、性能需求等。上面的例子只是为了解释应用架构的概念，面向下一代轨道交通的应用系统架构，将在下一篇文章中介绍。信息架构又称数据架构，是支撑业务架构的数据和数据标准的集合。信息架构依据业务架构和应用架构设计。例如进行客流预测，需要收集历史客流数据。明确每个数据项目的用途，如果数据项目无人使用，通常可以不用采集该数据。元数据，即描述数据的数据，如数据表名，数据列名，数据类型和取值范围等。元数据构成了“数据字典”。数据性质包括某类型数据存储容量、数据处理的实时性要求（离线处理/实时处理）、数据结构化程度（结构化数据、非结构化数据）等，数据的性质，对于在技术架构中选择数据处理方式非常重要。通常数字化转型项目中，将所有应用系统对数据访问的需求统一规划为“数据中台”。数据中台包含全部对数据存储、处理和访问组件。数据中台承担对数据的逻辑建模，数据的逻辑模型通常分为两个层次：对原始数据进行存储的结构化数据表，通常以数据的物理属性分类。支持应用程序的主题库视图，专题库可以横跨多张主题库表，同时可以对应用屏蔽主题库细节，简化应用对数据的使用，方便对数据进行访问权限控制。依据应用架构、信息架构，对支撑应用的技术组件进行选型。例如数据库、数据处理组件、应用中间件等。传统的轨道交通的行业系统，都是围绕着RAMS特性展开的。近年来，这些传统架构与互联网公司采用的架构相比，未免显得陈旧，因此在轨道交通领域引入互联网公司相关架构的呼声很高。但互联网公司对技术方面的贡献主要为高可用和高并发（吞吐量）架构。对Safety考虑较少，这一点在技术架构选型中要特别关注。轨道交通系统的产品的服役周期长达10～15年，系统都需要长期维护，如何避免诸如备品备件停产和IT技术快速演进对系统造成的迭代压力，也是技术架构设计中要面对主要问题。
（2）处理能力、扩展能力
下一代轨道交通系统技术架构面向线网级系统，远期往往需要接入数十条线路，而技术架构一旦选定，再进行大的变革就比较困难，因此，要特别注意系统的处理能力和可扩展能力。例如，通常一条线路的综合监控系统监控对象可达1～2万点/km，全网监控对象可达1000万点以上，随着物联网的应用这一数字还将增加。AFC系统全网交易量为每秒数千笔级别，且一致性要求高等等。传统的轨道交通系统，特别是生产IT系统，与系统外部网络均采用物理隔离的方式。但目前这一状况正在逐步被打破，主要表现在下面几个方面：互联网票务系统的运用，使内外网间的物理隔离被打破。下一代城轨系统对CCTV系统的应用日益重视，CCTV系统由于存在与公安系统接口，公安系统由于接入的终端较多且繁杂，而CCTV系统部件，如摄像机、NVR等设备安全漏洞频发。5G网络的应用，使基于运营商网络，建设城轨运营系统成为可能。此外，系统采用云计算技术以后，全网统一的运维系统对于全网有广泛的控制能力。权限分配不当或者管理员误操作等，都会对系统安全造成重大影响。综上所述，目前城市轨道交通系统面临的信息安全形势越来越复杂，需要在技术架构设计中给予充分的重视。除了上述考虑外，近年来，由于互联网公司的推波助澜，中台的概念比较火爆，IT系统建设都不得不考虑中台的问题。互联网公司建设中台的目的，可以简单的总结为，不重复造轮子，将尽量多的公用组件抽取出来，放在中台内，构建厚中台，小前台。中台策略适用于功能较为稳定的组件，如用户鉴权、商品交易逻辑等。对于业务需要快速迭代的模块则不合适，同时一个中台模块的变化会影响多个业务系统，互联网公司无不是通过长期的业务运营逐步总结出中台中包含的业务模块，中台的建设是一个长期动态的过程。针对轨道交通行业的数字化转型，不建议在建设初期规划太过厚重的中台组件，可以待系统稳定后逐步迭代建设完成。03机遇与挑战
线网化运营给轨道交通企业带来了前所未有的数字化转型机遇，通过数字化转型，可以极大的提高工作效率，节约成本，改善公司盈利状况。但也面临和很大的挑战。
传统的轨道交通企业内部，通常没有足够能力的技术团队对IT系统，特别是生产IT系统进行技术规划，依赖厂商又不可避免的为厂商所引导，在厂商商业利益的驱使下跑偏，使得完成的系统方案无法达到预期目标。数字化转型是一个长期艰巨的任务，需要5～10年甚至更长的周期，数以十亿计的投入并长期滚动迭代。没有公司高层长期稳定的支持是无法完成的。当前轨道交通企业的数字化转型大潮刚刚开启，下面是针对数字化转型初期企业的一些建议，或可以少走一些弯路。数字化转型是一个庞大复杂的系统工程，没有20年行业多领域的经验是不能胜任规划设计工作的。但是这样的人选凤毛麟角，而整体方案又不能没有统一的内部技术团队领导，否则将导致设计思想不统一，概念混乱，方案难以整合等问题。因此，必须组建内部技术团队，内部技术团队至少由10年以上工作经验的各部门业务骨干构成，通常需要经过3～5年的磨砺，才能初步胜任。数字化转型需要巨量的资金与人力投入，数以十亿计。但数字化转型的收益又是明显的，除了降低公司的成本外，还可以对外输出技术能力，实现收益。例如对外进行数字化转型咨询，对外提供相关产品和系统等。这样长期巨额的投入，在没有明确的商业计划的情况下，是难以成功的。创建合资或许公司是一条可行的路线，合资公司的作用除了进行商业运作外，还可以引进合作方的技术优势，为数字化转型项目服务，同时合作方的商业利益也可以得到满足。数字化转型需要长期持续的稳定投入，不可能一蹴而就，也不可能一劳永逸。所以需要通过长期小步迭代逐步实现。除了明确远景目标（5～10年规划）外，还要制定迭代步骤，每一小步以半年至一年为宜。小步迭代可以控制包括技术风险、财务风险在内的项目风险，避免人力投入过大，从一定程度降低技术决策失误对项目造成的影响。
