4月23日，中国城市轨道交通协会专家和学术委员会副主任李中浩就《纲要》的四、五部分进行了精彩的线上解读。解读内容深入浅出、干货满满。观众们给予了高度的关注，互动频繁，提问踊跃。下面根据直播整理了大家的问题和中浩主任的回答，以馈观众。想了解《纲要》解读最新动态，请扫描二维码加入解读交流群
A（李中浩）: 首先智能智慧建立在大数据共享的基础之上，所以生产指挥、运输组织、企业管理、旅客服务等所有应用都应该建立在一个IT平台。在这个平台上，作为运输企业各种专业都围绕运输走，作为企业都围绕成本走，对于旅客都围绕便捷的出行服务走，那么数据就可以实现共享。把智慧城轨分成几个体系就是人为的，比如也可以把它分成10个体系，也可以根据自身管理体系、管理组织架构将其进行分解。在智慧纲要编制过程中，经过反复讨论，认为分成八个智能智慧体系是较合理的。在智慧城轨推行过程中，我们坚决反对有某一个体系不纳入整个云平台中。我们今天在讲技术问题而不是管理问题，在管理上一旦出现例外，今天是涓涓细流，明天就可能发展成一条河，很快就会把我们所谓资源共享、数据共享的平台冲垮。比如，我们在智慧纲要编制过程中遇到这样的问题，视频信息与其他信息不一样，是海量的非机构化数据，要不要放在一个平台上呢？大家可以想一想，如果视频信息不在同一平台上，将来我们的智能化走到一半就会变成两个系统之内交易而不是在一个平台上进行数据交换，而人脸识别、生物识别、场景判断等很多应用都需要利用到这种非机构化的视频信息，这会给今后数据深度融合设置障碍。今天我们要做一个平台，是要把所有东西都移进去，请大家不要拘泥8个系统的边界在哪里，8个体系的分法只是给出方向，只是说我们可以把整个平台的功能分解成这样8个体系，这种分法经专家论证是较合理的。Q2：城轨业主是否应该成立一个IT公司来统筹规划智慧平台建设？A（李中浩）: 这个问题两说。因为IT人员的薪酬体系和城轨一般员工的薪酬不太一样，高水平的IT人员流失现象较严重。从另一个方面看，如果城轨企业就本身的IT应用要成立IT公司，能养得活吗？而如果没有一个IT公司，是否所有的应用、完善、提高都要外包，建立云平台以后，云的运行维护工作由谁来承担？这是一把双刃剑。针对整个信息系统、城轨云平台的维护问题，我们行业的IT部门一般的做法是，城轨业主与主要的IT应用供应商成立一家合资公司，比如宝信、民航信息集团、中铁信等行业IT企业除了为自身企业服务以外，还有自己的产品和能力为社会提供IT服务，也有一些企业的IT部门通过独立的公司形式仅仅是为自身企业服务。是否以独立的公司形式服务于智慧城轨建设，取决于各个城轨企业自身的环境与需求，不必强求一致。城轨企业的信息化云平台一定是私有云，因为谁也承担不起将来交通运输所产生的安全责任，这一点至少应体现在生产运营体系当中。在企业管理体系、旅客服务体系中大概率是采用混合云，在当前的外部环境下，一定会用公有云的某些服务，但是在生产体系一定是掌握在自己手里的。把所有专业都承载在一个共享的IT平台上，维护非常重要。那么这个维护需要外包吗？首先，我觉得在目前的城轨企业当中缺乏一个专业，这个专业现在正慢慢成长，那就是信息化专业。信息化专业在城轨运输企业中不是简单的维护办公自动化系统或者财务系统，而是支撑整个生产系统，是7×24小时的服务而不是5×7小时的。另外，现在比较多的企业采用的是成立合资公司的方式，从长远看我觉得这可能是个好的解决办法，就是说城轨企业和某一个承担你主要专业业务服务的IT企业构成合资企业来承担城轨云的维护问题，城轨企业可以做一些小的应用开发。对于有条件有能力的城轨企业也可以为社会提供IT服务，以此来减轻城轨企业自身的压力和提升自身IT能力与水平。Q3：智慧车站的定义与智慧城轨的定义有哪些区别？智慧服务中移动端要链接中心还是车站？智能运维以中心为主还是以车站为主？A（李中浩）: 今天我们在讲智慧城轨之城轨云，没讲实时控制系统。计算机主要发展两个方向，一个是实时控制或者人工智能，主要体现为及时、准确、低延时（以毫秒计）；另一个是通过数据来增加处理能力、提升管理效率的信息系统。车站在整个运输网络上是一个信息收集系统，也是一个运作单元，在网络发生故障，车站是独立运作单元。车站是连接实时控制系统和信息系统的界面，可以把它看成数据采集的中转站，所以我们在编制数据中心和共享数据平台的技术规范时并没有把车站纳入共享平台。我们认为车站是前端数据采集的一个集中点，在正常运营时，车站是运输网络中的一个节点。车站的运行需求需要认真界定，我们在做整体设计时要辨别清楚故障类型，在各种故障情境下，车站的功能定位。比如说在整个网络中断后，车站还能够正常运行吗？列车降级到站间闭塞模式时，车站应该继续接受乘客还是应该疏散客流？很多问题，当你把需求真正搞明白以后，车站的定义也会明确。在网络化城轨正常运营的条件下，车站只是智慧城轨运输中的一个环节。在解决车站各种系统的接入时，一定要十分关注信息安全。请注意在我们的城轨云网络安全设计规范当中，在车站是不允许各个专业系统和系统之间直接交换数据的，需要通过共享平台交换数据。在自动控制系统层面取决于供应商所供应的范围，目前已经划分成了综合监控、PIS等不同专业，如果是同一个供应商、同一个平台，为什么不能看成是一个专业系统呢？所以有一些供应商在车站层面用工业互联网来进行多专业的数据采集和控制，我觉得这是符合我们现在的整个规范和理念的。Q4：全自动运行要求首列车压道车运行，如果车站放一些车的话，那怎么处理？A（李中浩）: 停运时车站放一些车的做法是运输专家提出来的，我们认为有道理，因此把它写入了智能运输组织的章节，我们不能以今天的管理模式去适应未来智能化的轨道交通。如果未来的轨道上、接触网上有众多传感器，包括列车和各个专业系统，均很清楚自身状态；从运行角度，列车很清楚前方有没有人或其他障碍物，如果这些都能辨别，为什么还要压道车呢？所以将来智能化以后的生产管理等很多规章制度不是用今天的眼光来看的，我们要假设很多信息可以被感知并且已经被集成了，我们有了智能化的判断能力，在这样的一种情况下在车站放一些车是可行的。Q5：信号系统对于地铁运行至关重要，但信号设备的智能运维系统要怎么实现呢？A（李中浩）: 信号系统在轨道交通各系统当中是重中之重，把它当宝贝一样捧在手里。信号系统不出故障则罢，一出故障你的老板肯定乌纱帽丢掉，甚至市长也会受牵连，因为要么不出事故，要出事故都是大事故。信号系统的信息化的“0”和“1”和我们平常的“0”和“1”不一样，在城轨云中我们只是在线路ATS这个层面和信号系统接口，将ATS的非实时控制功能纳入路网控制进行数据共享，列车运行的安全由信号系统自己来完成、自己组网，这也是我们为什么一定要私有云的一个主要原因。信号专业系统可以看成边缘云，是工业互联网系统，本身就应该具有智能化的特性。这样的话所有的关于设备的状态数据是可以根据需要被感知的。在掌握了全面的、及时的、准确的数据以后，做到信号系统装备的健康管理是水到渠成的事，智能维护很多问题可能是在传感问题、软件问题。我相信现在的信号企业应该有这个能力，当然前提是需要将这个智能维护体系建立在城轨云的网络架构上，实现路网化管理。综上，信号系统的安全问题和智能实时控制问题责任还在信号系统，但是我们一定是实现信息共享，因为整个智能运输指挥是以信号为笼头的。Q6：地铁和城际铁路如何实现上线和下线运营，接触网电压不同如何实现？A（李中浩）: 接触网电压不同就是列车采用双流式供电，这一点不难实现。比如25000V的单相交流供电的城轨列车，车上的交直交牵引传动系统的中间直流电压是1800V，相当于到了直流1500V供电区间不要交直部分，就直接接入交直交变流系统的直流侧供电就行了。受电弓需要分别设置，因为在同样速度情况之下，电压低了电流就大。我们国家的双流式电力机车已经出口到南非，所以在技术上双流制式是没问题的。另外一个就是信号问题，25000V交流供电的区域信号制式一般采用基于轨道电路的CTCS-2与城市轨道交通采用基于无线车地通信的CBTC是有区别的。通过我们的技术，信号系统供应商已经研发出了这样的车载装备，使其对两种形式的轨道电路都能适应，这样一来如果限界没有问题的话，列车就可以开过去了，实现互联互通了。Q7：随着区域经济发展趋势，城轨建设的多业主模式对智慧城轨建设或有不利影响，如出现多个云平台、智慧标准差异等等，能否谈谈如何引导或理顺多业主建设协调关系？A（李中浩）: 这取决于整个城建部门领导的认识，在技术上讲用一个云平台没有问题。比如北京就是多业主形态，但北京只有一个运营指挥中心，其主要管两件事，即运输指挥调度和票务。我觉得这个制式就可以，它就是一个云平台，各家单位可以共建共用。但是有的城市可能会建两个云平台，这主要取决于管理模式，在这种情况下，如果两个云平台按照同样的规范建造，上面再加一个扁担，以此来解决跨线运营问题和网络化运营，整个路网的功能不会受影响的。我们认为信息化建设很核心的问题是一定要和管理体制相结合，一定要保证数据来源的准确、及时和完整，这是问题的关键。有条件，建一个云平台；没有条件，建两个、三个再搭个扁担都没问题，关键是不要各个专业分散建网，不要一条条线路分别建网。Q8：到2025年智能车辆要占到新造车的95%，请问智能车辆如何来理解？A（李中浩）: 比如说高铁上面有将近两千多个传感器，能感知整个高铁列车的健康状态，其实被感知之后还需有模型支撑，比如说轮对轴承，可以通过三相电流的大小、波形来判断轴承的故障和健康状态，这取决于轴承的智能检测模型，所以关键点在于传感和智能计算。我们国家现在的制造技术对于车辆能够做到智能感知、实现整车的安全性、装备的健康性、、易损易耗件的可用性等，技术已经达到一定高度，增加不了多少投入。但是我们要提出要求、提出应用，这些数据传下来怎么办？如何建立我们的智能维护体系。比如说我们增加了一些接触网的感知，并且对车地通信提出了很高的要求，要求把这些视频信息实时地传到地面，传下来如果没有相应的管理体制跟上，传下来的这些信息就是垃圾。后面的工作中，一定要注意智能车辆跟我们的管理模式相结合，传什么、存什么、处理什么、什么东西在什么地方处理、什么东西要共享都要搞清楚。那么多车在跑，谁在管？谁在看？所以我们没有必要把所有接触网信息都实时传下来，完全可以先存起来，有问题时再看。要是跟智能车辆本身结合起来的话，我觉得只要我们有要求就可以实现，而且不用增加多少成本。Q9：无感安检，背双肩包或小包的乘客可否结合实名制直接刷脸进站？东京、纽约、伦敦都是不安检的A（李中浩）: 这取决于各个城市的管理模式和管理理念。在我看来关键是社会的信用成本有多高，如果人们非常珍惜信用，尤其是一旦你失信将要跟随某人一辈子的时候，如果这个人一辈子没做过坏事，为什么背个双肩包就不能进呢？所以这里面不仅仅是技术问题，还有管理问题、管理理念问题，在技术上是完全可以做得到的。这里还有与政府其他部门的职责关系，我相信在保障安全的前提下各个城市都会有自己的处理办法。Q10：若是智慧安检将安检与AFC系统闸机整合，是安检厂家还是AFC厂家做比较合适？A（李中浩）: 这取决于安检厂家和AFC厂家的能力。我认为从应用角度来讲哪个厂家来做都没有关系，但是如果安检厂家做了前端的凭证检知和安检结合，那么与后端的清分系统、互联网票务系统怎么结合呢？目前来看，这实际上是由谁来当集成商的问题，如果安检厂家当集成商，需要结合AFC厂家，反之亦然。从纲要角度来讲，没有涉及这么细的问题，但是我们觉得票务和安检的融合尤其是在实名制的情况下应该去大力发展。Q11：请问新兴城轨企业开展城轨云的最佳时机在哪个阶段？城轨云的规划是否应该与线网建设规划同步进行？A（李中浩）: 新兴城轨企业是我们最希望能够完全贯彻纲要的单位。不要担心你的管理模式还不够成熟以及是不是需要一步到位，我们再三强调云平台架构一定要一步到位，至于应用可以一步一步来。比如说呼和浩特的城轨云实践，他在上云平台架构时只有一条线、城轨还没有网络化。在开始的时候就按一个城市一个路网指挥中心建设，等到2号线建设的时候就不需要再重复投入了，上了云架构以后大大的提升了CPU的利用率，减少了计算机数量、机房面积。所以我们讲城轨云的建设不是费钱而是省钱。目前北京的思路也告诉我们，城轨云基础架构本身如果从整个线网的角度来看肯定是省钱的。如果在城轨云平台加了很多智慧化的内容可能会费钱，但是这种智慧化内容对于建设时所化费的钱是一定能从日后的运营管理上要回来的。传统来讲，信息化的投入产出比一般是1:7，所以说基础设施平台建设时千万不要犹豫，就按照规范来。我们城轨云的规范实际上是借鉴了大铁路的经验以及各位老大哥城轨企业的经验，所以新建城市不要担心生产关系跟不上，完全可以大胆的上。有一点是可以肯定的，你用这个平台做到什么程度、管理到什么程度与一把手的管理理念密切相关。应用系统一步到不了位，可以分解了逐步完善，建议大家采用拿来主义，充分吸收老大哥单位的经验。我们的设计部门从一开始都参与了规范的编制，他们肯定有能力来满足你的应用要求。A（李中浩）: 我觉得智慧城轨是最合适不过的新基建，智慧城轨的建设完全符合新基建的理念。我们完全可以理直气壮的说，智慧城轨建设就是最好的新基建。而这个新基建是真正将我们国家长远期经济发展和短期经济效益结合起来，拉动经济发展的最好抓手。我们现在做的这些工作和新基建的理念完全吻合，我们就是新基建，但我们一定要做名副其实的新基建，不要建设一条崭新的旧城轨系统。Q13：城轨云的出现是否影响了传统的分专业运维模式？在运营界面上出现新的定义？A（李中浩）: 一个专业的运维在网络化以后，对于各个专业应该是各条线一个运维系统，而不是一条线一个专业是一个运维系统。在我们的城轨云里面，数据也是以专业为第一分类，以线路为第二分类。上海做的不错，在一个路网的角度来思考整个运维体系。上了城轨云以后，城轨企业从条块管理进入矩阵式管理，就像军队，兵种管建设，战区管打仗，运营就是管战的，装备维护就是管建的。上了云以后各专业系统的维护也已经矩阵化，矩阵化以后，运营维护组织肯定是要改的，但是可以渐进式的变革，认识到一点改一点，认识不到可以慢慢改，前提是以数据为基础，没有准确、及时、完整的数据就没有做成综合运维的可能性。信息系统或信息化建设一定要能够提升生产力，这是建立在调整生产关系基础上的。生产关系的调整可以采取温水煮青蛙的方式，是可以慢慢地渐入佳境的。Q14：请问深度融合、车车通信最终是否会导致车辆专业消化掉信号、通信专业？A（李中浩）: 车辆专业是既有的边界，信号专业是既有的边界，在信息综合融合以后，车辆专业里面有信号专业的内容，尤其是在车上；信号专业里面也有车辆专业的内容，尤其体现在全自动运行和调度指挥上这是发展中的好事，前提是看这种融合对我们的装备是否有更好的提升能力。我认为现在的车辆专业都已经在往信号专业走，现在的信号专业也已经在往车辆专业走，比如说车辆网络的问题，取决于你的实力，取决于你能提供产品的质量，取决于你对整个问题的认识和水平，从业主的角度，我要的是物美价廉的东西。我觉得这种融合是符合发展规律的，前提是做这种融合的企业眼睛要看远一点，想的是要为乘客服务、要为业主服务，不要只想着如何使自身企业变得更大。如果一个企业没有社会责任意识，仅仅用技术发展的眼光去做这样的扩充，最后会走不下去的。但是我并不担心这些专业之间的融合，比如说车辆的水平、车辆的整个控制系统，我觉得将来就应该信号系统、制动系统和牵引系统融为一体，用一张统一综合车载网来做实现所有的列车控制功能，这很客观。至于到时候谁来做无所谓。Q15：目前的标准部分条款对于智慧城轨建设是有制约的，当出现冲突的地方，如何保证智能技术能有效运用到建设中？A（李中浩）: 这恰恰是我们协会现在在做的事情，我们拼命在推进设计规范的编制，就是希望尽早给你们有一个依据。实际上采信规范完全取决于自己的主观能动性，现在已经发布了“智慧城轨信息技术系统架构和网络安全规范”，根据《纲要》的“1352”城轨信息化标准化体系正在紧锣密鼓编制，争取今年年底能够发布。有了依据，你就可以把它当面旗子。我们现在是尽可能地给大家竖个旗杆，尽可能给大家提供标准和规范，我们希望我们的设计规范今年年底能够出来。现在你只要说你可以采用城轨云，那么各大设计院一定会积极响应的。Q16：如何考虑城轨云高可靠性、安全性问题，云一旦失效，影响是灾难性的。目前互联网公用云出现过故障失效影响服务，维护人员意外删除应用数据的情况，机房火灾也是一种隐患。A（李中浩）: 城轨云是一个信息系统而不是实时控制系统，城轨云融合各个专业的自动控制系统才能够支撑城轨运输。极端的说，城轨云即使瘫痪了，这条线路上车也不会撞车。我们现在设计ATS到了线路级以上才和城轨云相连，ATS以下仍是CBTC信号专业的系统。CBTC是实时控制系统，我们是在实时控制系统下采集数据才形成城轨云的共享数据。城轨云采用了虚拟化等先进的IT技术，在计算机网络性能上大大的提高了可靠性。因为了实践已经证明云架构的可靠性比其他网络拓扑结构高，骨干网络是双重冗余配置，只可能比原来的架构可靠性高而不会低，很核心的问题在于如何建立运行维护系统。不能既要马好又不让马儿好又要马儿不吃草，我们的城轨企业决定采用城轨云，就下决心要同步要建立自己的信息技术部门，而且这个部门要定位在生产系统。建设城轨云必须同步建设城轨云的运行维护平台，网络安全问题只要真正按照我们的网络运行规范、网络安全规范去做，只要做到这些，云平台的安全是有保证的，只会比原来的系统更为可靠。城轨云定位在私有云不是公有云，在从Internet到数据平台有若干个防护门槛，网络安全七分管理三分技术，在任何时候不能忽略管理的重要性。Q17：私有云里面生产系统的边界在哪里？哪些分为生产系统？A（李中浩）: 8大系统中都有内容属于生产体系，比如说信号、车辆、综合监控、PIS系统、门禁系统、AFC等专业系统都属于生产系统。要确保运营生产的安全，从网络安全角度过去这些系统有的是二级等保有的是三级等保，我们把它比喻为原来门卫守在楼门口，建设城轨云以后，我们将门卫变成守在城墙门口，所有城墙里面专业是可以相互信赖的，信息充分交互，这才能够达到信息共享的目的。城轨云分成安全生产、企业管理和旅客服务三张网络，设计有14个边界，这些边界在我们的网络安全规范里面都有明确规定，希望大家能够认真去解读，因为已经发布了智慧城轨网络安全规范的总体部分，下位关于城轨云的网络安全规范下周28号进行征求意见稿的专家评审，我们加快编制进度，尽可能早地提供给大家。信息安全是有投入的，只有从顶层设计从网络抓起，才能打下较好的基础，网络安全在规划时期就要安排，从城轨云建设的初期就要充分认识。Q18：城轨的大数据应用离不开相应的专业人才，目前行业这方面的人才比较缺乏，这方面是否会引导相应院校开展相关专业呢？A（李中浩）: 城轨的大数据应用我们的观点还是应用导向，从学校里面去培养专门针对城轨行业的应用人才是不现实的。但是在我们既有的熟悉城轨业务的同事需要药加强对大数据应用的学习，能提的出需求；涉及到大数据专门知识的时候，运用大数据专业的专门人才。在城轨信息化过程中已经涌现出一些在大数据方面比较好的企业，包括在编制大数据规范的领头企业等等，这里都有我们大数据应用的各个梯次的人才。有很多知识是在在实践当中不断增强的。大数据应用的关键还是在数据来源的问题，先建立平台、运用启动，慢慢地我们会对大数据应用会有更清晰的理解。作为大数据平台，我们在规范里规定的是开源平台，是为了能够引入带标记传输，掌握大数据运用的主动权，这对大数据平台应用有一些基本功能诉求，需要一些软件支撑，希望大家在建设的时候引起注意。人才的问题永远是个问题，可以用建立合资企业或其他模式去解决，这些都需要通过实践去摸索。我认为将来所碰到的问题可能首先还不是大数据使用和人才的问题，而是如何能够用这样的信息化或智能化的理念来结合我们的传统产业和管理的问题，信息化建设，管理问题始终很重要。Q19：关于智慧城轨纲要与地铁设计规范在专业和系统的划分上是如何界定的？A（李中浩）: 上了城轨云以后，从原来条块管理转换成矩阵管理。各专业的IT基础（网络、存储、计算）由云平台承担；专业的传感、控制、功能仍由各专业负责；只是1、各专业要从路网角度考虑，而不像以前仅仅考虑单线；2、有了跨专业的共享数据平台，会有很多现在没有的增值功能，要充分发掘应用。换言之，如果出了故障仍找各专业系统，云平台只是起到基础支撑的作用。从网络架构角度看，信息系统与各专业（如综合监控，PlS，AFC等系统）自动控制系统（工业互联网）的接口在车站，路网中心功能全部由云平台承担。工业互联网也可看作城轨云的边缘云。除信号系统，要避免其他专业不经过城轨云网络直接通过线路骨干传递信息。从边缘云的角度，可以在车站集成现在定义的各专业的信息并加以车站的应用。运营发展的方向当然是网络化运营，除轨道交通的3网融合外还有与其他公交的融合。我认为其纲是向乘客发布运营时刻表，这是我们和日本、德国城轨运营的主要差距。
