回到20世纪80年代末，城市轨道交通AFC系统概念在中国还是一片空白，各地的地铁建设管理单位和运营单位需要以相当的篇幅对人工收费和自动收费的利弊作分析，以说明自动收费的重要性。那时对AFC系统的功能设置是以学习国外成功的系统经验为主，其间香港地铁给予了内地同行许多帮助，将他们宝贵的建设和运营经验传授给内地；同时国际著名的AFC专业厂家，如美国的寇比克、法国的CGA（后来被泰雷兹收购）和日本信号等，通过产品和系统的推介，把AFC系统许多优秀的技术特性推荐给了国内地铁公司，这些都为广州地铁和上海地铁的AFC系统在建设之初就拥有严谨和基本完善的系统框架奠定了基础。

1988年，上海地铁凭借在国外收集的资料，艰难地开始了AFC系统和设备的试制，并在上海地铁1号线的徐家汇等车站成功试用，结束了人工售检票服务的时代，我国AFC系统之路正式开启。而后，随着2000年前后国内第一轮城市轨道交通建设高潮的到来，北京、上海、广州、大连、天津、深圳、武汉、重庆和南京等城市轨道交通项目陆续上马。在这一轮建设大潮中，AFC系统不再是“豪华配置”，而成为了“标配”。

国内AFC系统潜在需求市场的不断扩大，吸引了一大批国内的高新科技企业。而在最早迈入AFC时代的上海，已经汇集了一批AFC行业的精英人才。在这一阶段加入AFC行业的国内企业，一方面纷纷从上海引入技术人才，另一方面积极与国外厂家合作，引进消化国外先进技术，因而他们研发的软件架构在思路设计理念、架构模式等方面都具有相似性。

与其他同行企业不同的是，中软AFC的软件架构，更多是在向日本信号学习的基础上，借助自己在证券行业的经验，独立自主研发而来的。中软AFC走上了一条与其他企业不同的、有中软特色的AFC系统研发道路。

在北京地铁13号线升级改造项目和首都机场线项目中，中软AFC的软件架构靠着摸石头过河，一点一点“攒”了出来，有一定的独特性。软件研发人员大多是做证券软件研发出身，对AFC技术、业务的了解还不是很深入，但即便还存在一些问题，中软AFC还是保障了前期中标线路的开通。

在V1.0、V2.0、V3.0时代，中软AFC的项目数量并没有对AFC系统的研发构成挑战，给予了软件研发中心相对充足的时间来进行系统的沉淀、研发升级。考虑到中软AFC的市场将会不断扩大、项目数量不断增多，对于软件研发适应项目并行的要求也在相应提高。随着技术的发展和对客户应用理解的深入，产品化正在成为产业成熟的决定性标志，也是市场成熟即将进入快速增长的最重要的风向标。2010年年底，中软AFC启动了产品化设计。

在对“如何能使项目化的工作与产品化的工作有清晰界限，如何让项目化的过程能顺利推进”等问题进行了深入思考后，从V3.0开始，中软AFC软件研发中心引入产品化的理念和思路，一路经过V4.0、V4.1、V4.2，持续优化提升至今。

在V3.0平台设计完成并初见成效后，软件研发团队又进一步在主体业务流程层面进行了深化梳理，形成了更为全面的平台体系——V4.0平台。V4.0平台的设计目标主要围绕AFC核心业务的整体梳理。V4.0体系下的“终端V4.0”的研发与V3.0体系下的“终端V3.0”的优化不同。“终端V3.0”是在V2.0的基础上，对系统进行的局部优化、业务梳理，而“终端V4.0”则是以产品与项目的边界为考虑重心，同时借鉴V3.0的既有业务积累，沿用原数据存取机制、通讯进程的逻辑，以及对象配置化管理的设计理念，对面向乘客的核心业务从最基础的进程间通讯机制做起，进行了重构。这是从根基处开始的调整。由于牵涉面较广，这一次产品化设计的周期特别长。

2013年7月，V4.0体系下的“终端V4.0”研发开始筹划并启动。这时，以V3.0版本为基础的哈尔滨地铁1号线、北京地铁14号线等项目正如火如荼地进行现场实施。由于大部分研发资源都被投入在建项目中，前期产品化的工作推进并不顺利，磕磕绊绊地进行了一年。2014年，大连地铁1号线开通时，仅有局部模块按照产品化初期版本的思路得以应用。直到2014年底，还没有成型的产品化平台可供项目化开发。

几乎所有人都意识到，这种状态不能再持续下去了。2014年下半年至2015年年初，广州、南宁、长沙等地的项目陆续中标，项目终端平台的抉择迫在眉睫。杜潜开始与软件研发团队讨论，是否将新的终端平台应用于新的项目中，内部意见产生了很大分歧。在对中标项目的开通周期做了初步评估后，中软AFC最终选择了启用新的平台来应对新项目的交付。

第一个启用新平台的项目是广州地铁4号线南延段项目。2015年春节后，中软AFC加紧部署产品化平台封闭研发的计划，按照广州地铁4号线南延段年底开通的总体计划倒推，初步计划在2015年5月1日前，完成第一阶段平台搭建，后续再逐步扩展业务功能。屋漏偏逢连阴雨，不同于以往北方地铁项目在地铁开通时才验证软件，广州地铁业主方要求提前半年在真实车站、真正面向乘客使用进行软件下站测试，将中软AFC终端研发团队打了个措手不及。

时间很快就到了2015年5月，留给终端研发团队的时间已经不多了。为了应付6月的下站测试，在平台尚未搭建完成的情况下，5月初，终端研发团队稍作调整，抽调了一批极富经验的总工、开发、测试资源，大队人马浩浩荡荡奔赴广州进行封闭研发。杜潜来到现场确保项目的推进。(www.daowen.com)

五六月的广州，天气又闷又热。项目节点目标极其紧张，现场条件极其艰苦，研发人员只能熬夜突击。平台初建，大部分资源还处于模块化参与的程度，几乎没有人熟悉整个业务流程，对业务整体性也没有全面理解，纵使有通天的本领，也无计可施。只能伴随着问题的暴露和时间的推移来不断完善。2015年6月的下站测试暴露出很多问题，研发团队疲于应对，引起了业主的不满。这种混乱的状态一直持续到2015年9月，总算勉强应付了项目节点。

在此期间，“BOM软件与产品化模块对接”的工作也在同步推进。“终端V4.0”软件系统架构在设计之初并未考虑BOM。但从V3.0开始，整个终端已经按照统一设计、模块复用、通用业务复用的模式在组织开发产品，平台的升级不可能缺失BOM。李小明接过了BOM软件架构与“终端V4.0”平台对接的重任，在既有BOM软件架构的基础上，开始了“产品化模块对接”的研发。再加上BOM的界面需要按照广州项目化开发，业务逻辑也需要重新梳理，通讯进程等模块还需要统一设计，难度可想而知。据当时深度参与广州地铁4号线项目的工作人员回忆，仅读卡器模块接入产品化平台这一项工作，就耗费了李小明一个多月的时间。

2015年7月起，南宁、长沙等地的项目也陆续开工，与广州地铁4号线项目交织在一起。2015年整整一年，软件研发团队都在异常的忙碌、困惑、痛苦煎熬中度过。正在焦头烂额之际遇，2015年年底，广州地铁方面传来消息，庆盛站因故推迟开通。终端研发团队终于得到喘息的机会。

广州地铁4号线项目的“终端V4.0”是中软AFC软件研发团队在V4.0平台下研发的第一个版本，存在很多的缺陷和不足，每年都需要投入较多的资源进行维护、完善，直到2016年年底，随着V4.0平台的逐步稳定和成熟，通过对广州地铁4号线项目车站、设备系统的升级，广州地铁4号线项目的系统运行才进入了一个平稳的时期。

同样受到影响的项目还有2016年6月开通的南宁轨道交通1号线项目、2016年5月开通的长沙磁浮项目、2016年6月开通的长沙地铁1号线项目。

南宁轨道交通1号线项目对于南宁技术实施小组来说，是最具有挑战性、最有压力的项目。2016年2月底，南宁技术小组人员陆续进驻第一现场，开始长达4个多月的开发调试、现场实施工作。

南宁轨道交通1号线项目是在广州地铁4号线项目的基础上进行开发的，整体系统功能并不完善。南宁技术小组面临着双重压力，一方面来自外部，现场面临各种验收，业主对中软AFC整体系统功能以及项目进度并不满意；另一方面来自内部，负责“终端V4.0”研发团队的组成人员都是中软AFC软件研发的新手，经验不足，再加上长沙磁浮项目与南宁轨道交通1号线项目节点要求一致，设备、开发资源严重不足。

负责南宁轨道交通1号线设备软件系统研发的龙金贵是软件研发团队新生力量的代表，他一人担负TVM、AGM等多个设备整体功能的研发工作，这在中软AFC的其他项目中，也是鲜有的。在那段时间里，已经成为中软AFC技术部负责人的李美贵，穿梭在长沙和南宁之间，指导解决技术难题。加班熬夜，通宵达旦已经成了他的家常便饭，双眼里更是经常布满了血丝。

最终，软件研发团队攻克了一个个技术难题，经过4个多月的艰苦奋战，南宁项目于2016年6月28日成功上线。团队成员经过项目的锤炼，也都能够在各自的领域中独当一面，成为后续各项目研发工作的中坚力量。

在广州、南宁、长沙项目的磨练下，“终端V4.0”平台日趋稳定，为终端自动设备提供了可持续发展、快速交付、快速扩张的能力。在没有“终端V4.0”前，由于项目边界等方面不清晰，对技术人员的业务和编码能力要求较高，实施一个AFC项目，每个专业组几乎都需要全员参与；多个项目加起来，需要投入十几个研发人员，并且要求所有人员都较全面理解全系统的代码结构；对于最为复杂的TVM软件，则更是牵一发而动全身。“终端V4.0”平台完成后，由于核心业务均由产品化平台进行了统一的处理，一个完整的AFC项目只需要前期几个资深资源阶段性地集中处理即可基本成型，后期可以交给团队梯队资源。

产品化的设计理念有效确保了核心骨干可以集中精力办大事，既确保了技术的把控、设计的统一，也为多项目并行化开发创造了条件。