各位专家各位领导大家下午好!现在由来我汇报一下云平台在温州铁路AFC的应用。本次汇报有6个部分组成，首先简单的介绍一下AFC的系统。

轨道交通数据也就是我们常说的AFC是由计算机、自动售票、自动检票，以及票管理，财务结算，客流量分析的轨道交通的业务自动化的管理系统。简单点说这个系统主要是解决钱、票和数据三种关系的系统。目前AFC系统的设计工作实施的是参照着国标顶层架构展开的，第一层是轨道交通的ACC，第二层是计算机系统LTS，第三层是车站的SC，第四层是现场的终端设备，第五层是车票的读卡器，其中我们相对于ACC系统和LC系统定义为中央级，车站计算机系统定义为车站级。ACC系统是整个轨道交通线路AFC系统最上层的管理中心，在建设层面上我们用四个中心来概括。其中第一个是系统运营的管理中心，第二个是票务信息的管理中心，第三个是线路之间的协调中心，第四个是运营状态、监控管理中心。ACC系统一般都是设在线网控制中心，属于第一条线网的建设。线路ACF系统是实现了线路内部的交易数据和监控数据的升级、分析并上传给内部中心，也就是ACC，实现在主线路出票和车卡的一个调配，实现对线路运营状态、监控、处治命令的下发，与ACC的对照，接受上级下发的车票准备，票价运营模式等参数给相关火车站，实现线路内部的安全精准的管理。

车站计算机系统主要是针对车站AFC终端设备进行监控，实现对车站AFC系统的运营、收益以及维修的集中管理，终端设备主要是包括了供乘客使用的自动售票机，自动检票机，以及闸机，以及工作人员操作的自动售票机。

目前这个系统在整个车站均采用了IC卡车票，种类包括了单程票、储值票、乘次票、旅游票、纪念票、出站票、员工票等等，票的种类可以根据需要进行增加。

第二部分介绍一下温州市的服务。温州市轨道交通线路是由6条线路组成，总线路是361.8公里，设站是128个，换乘站是14座，其中市级线路是SE到SC总共有4线，线路组成是25.3公里，市区现在是2条，线路是92.5公里。发改委关于温州市轨道交通规划，延续了2012到年2019年实施S1线一期工程S2一期工程和S3线工程，线路总长是140.7公里。目前正处于建设状态的是温州市S1线一期工程，这条线路的全长是53.51公里，一共车站是19个，其中地面站2个，高架台14座，底架台3座，并预留了两个车站，近期的站间距的是3.13公里，远期大概是13公里，设立控制中心，同时线网工程以及S1一期工程是同期建设的。

S2一期是10月份刚刚拿到了设计的批复，目前正在进行招标，最快是明年上半年开工。S3一期正处于工程的阶段，属于前期的设计阶段。

S1一期系统当时是分成了两个标段，一个是AFC系统，2015年上半年完成了ACC系统和线路AFC系统招标，2015年下半年完成了ACC系统的设计联络，2016年上半年是完成了线路FC系统的联络和AFC系统线网标准的AFC，2016年大概9月份由中国轨道交通协会专业委员会完成了温州AFC系统升级方案，同期完成了温州AFC系统线网化标准，计划今年年底完成终端设备的样机运行，和ACC云平台在温州现场的搭建工作。

第三部分介绍一下温州AFC系统的具体架构。刚才已经介绍了我们现在的AFC的架构是按照5层的架构展开实施的，考虑到温州线路网的特点，我们将第二层线路中央系统ACC取消及部分功能合并到中心系统，将传统的架构给全新的4层架构。4层架构主要体现在，从线网的层面上来看建设的工作较低，由于系统云化升级之后系统的速度更高，数据的多样性更好，符合未来发展的需要以及大数据的要求。当时的设计是在2013年，受到了技术的限制，主要是过多占领了同时介入线网ACC系统就造成接入压力，容易形成途径，从而降低了整个系统的性能。针对此问题，在ACC系统和AFC之间增设了交换机等接入设备，对于一条线路传上来的数据，然后再传给ACC系统，分担了ACC系统的接入压力。其实这个问题从技术上就能解决，因此考虑到S2S3线可能取消接入交换机，让SC系统直接联SC系统。

第四部分是云平台的运用，因为温州AFC系统采用了4层架构，相当于ACC系统功能进一步的扩大，功能更强，因此我们结合了当然计算机的发展水平提出了云平台的方案。在此之前先回顾一下AFC系统的传统的方案。主要是四部分：第一部分是有一个小机，主要完成的是管理子系统，供他们使用;第二部分是存储设备;第三部分是多台PC服务器，供各类子系统使用，一般的每个子系统对应一台或者多台的体系;第四部分是网络设备，包括交换机和防火墙。而云平台主要是三部分：第一部分采用的是基于X86架构的一体机，能完成各类数据业务。第二部分是多台PC服务器,也是基于X86架构的，给其他各类系统共同设置的，第三个部分的网络设备与传统方案一致。从硬件上来讲，传统方案和云方案的基本差别并不是太大，从软件上来讲最主要的区别就在于存储的位置，传统方案在制定的一台或者是多台或者是PC的服务机上，而云方案的软件是在虚拟机或者是云平台管理系统，云方案能够很好的解决了设备的单点故障问题，同时还可以很好的解决资源共享、合理分配资源、系统弹性增长一直困扰的传统ACC系统建设时出现的问题。

这两张图就是温州现在的ACC系统的系统服务，主要是三个部分组成的，存储池、计算池和资源池，存储池刚才说了是用一体机组成，计算池是采用了18台新华三的服务器，网络池是存在了新华三交换机和6台兼容交换机，同时整个云平台的燃烧也是采用了新华三的云平台管理软件。考虑到系统的安全性，可能在异地设置了一套系统一级系统，大的整体架构是能够和系统保持一致，也是采用了云的方案。

前面讲的基本上是硬件，我们认为的还有一个云平台的管理软件，它有一个好的软件就是必须要有基于集群的集中管理，还有高可用性，动态的资源调度，具有完美的生命周期管理，同时在各种性能的监测，包括了虚拟机的虚拟交换的一系列网卡中的，它能够进行全面的资源调配，并且对动态资源扩展。

第五部分是需要解决的问题。在一个系统建设前，首先看为什么要建这个系统，它的需求是什么，主要是基于两点：一个是业务的可用性，第二个就是运维的管理，同时要兼顾的成本节约，也就是最大化投入回报。基于以上几点，我们做了一个系统性的架构。如果是AFC专业的话基本上都是系统级的容载，虽然在系统上是很好的，但是在后期运营其实是一种资源的浪费，这个系统常年不用，因为主系统ACC从这多运营的城市来看很少会出现故障，所以一般像我们投资千万左右，其实是造成了资源的浪费。如何有效的解决这一部分设备的使用是我们面临最主要的问题。基于此，我们现在是两种云，初步的设想是将这两种云变成一种云，可以解决一部分的问题。

下面后续的展望和主要内容。 我们的想法是采用现在比较流行的双核双中心的方案，让容灾系统也到这个管理中来，主中心系统作为整个系统的中心，同时应用服务器集群在平时作为资源池的资源参与到日常的ACC系统的业务处理当中来，只有有ACC的主系统出现故障或者是崩溃的情况下，提升为中心级替代整个ACC日常运维的连续性。这样做的好处是可以有效的控制成本，同时还可以提高AFC系统设备的使用率。

我们想进一步的将云平台的规模扩大，实际上AFC系统简单的划分为两部分，一个是前端的数据采集，第二个是后端的数据处理。数据采集主要就是由SLE及读卡器、车票量化完成，后台的数据处理主要由服务器存储设备来保障完成。S1系统当时设计的时候也是有这方面的考虑，所以前面介绍了所有的网络都是基于前端设计的，如果后期条件允许，或者是各种情况都满足的情况下，我们会做大，像SC系统已经纳入到整个云平台的管理中来，我的汇报就到这里，谢谢大家!