延长线就是在既定线路的基础上，从某一终点，继续向既定线路行驶方向进行延长工作，最终完成后，仍可视作一条线。

根据运营和系统集成施工、验收经验，论述并分析广州地铁3号线综合监控系统新功能，以及延长线和首期在运营控制中心(OCC)的衔接扩容方法及方式，并对综合监控与企业资源计划 (ERP)技术的进一步融合提出展望。

延长线与首期工程的设计时间相差4年，其间维护、使用 ISCS(首期称为 “主控系统 ”，main controlsystem)的运营人员有针对性地提出了意见和建议,根据科技的发展对其部分功能进行了扩展和更新，使延长线的ISCS在不少方面都有所创新。

1) 根据运营维护、使用人员在首期工程中站名变更困难、造价高的情况，设计了车站编码原则，并要求新车站据此进行编码，增加站名更改的自由度。

2) 根据FAS系统没有独立的网络通道来共享信息和维护终端的情况，延长线借助ISCS的赫兹曼交换机划分出虚拟局域网 (virtuallocalareanetwork,VLAN),将FAS维修信息传送至车辆段FAS的维修工作站，给FAS提供便利的数据通道。

3)延长线设计OA系统通过网页浏览器经防火墙连入主控系统，并查看主控系统车站/OCC的历史事件和报警功能，进一步增强和ERP的联系。此功能将进一步向现场设备故障—ISCS报警—ERP系统启动—产生维修工单 —配置和计算物料、人力消耗 —统计维修成本的方向发展。

4)自动、快速地计算出后车里程是延长线新增的功能之一，如果列车在隧道行驶过程中发生火灾，由于环境闭塞，一旦烟气充斥，后果将极为严重。作为应急措施，隧道通风系统会根据列车着火位置 (车头、车中、车尾 )、列车同隧道风井的相对位置、后车相距位置等因素综合考虑，启动正确的隧道通风模式。在此前提下，如何快速地计算出后车相距里程，并结合后车与隧道风井、站台等排烟通道的相对位置，对于启动正确的隧道通风模式、最大限度地降低乘客伤亡尤为重要。

介绍了西安地铁2号线延长线自动售检票（AFC）系统接入原有已运行系统时，AFC系统与综合监控系统在综合联调中的对接联调方法。通过搭建模拟测试环境、增加冗余服务器、调整联调时间等方法解决2号线延长线AFC系统接入已正常服务的综合监控系统时存在的AFC联调时间紧张、延长线与一期工程数据点表不一致等难题，在不影响现有系统正常运营的情况下实现了延长线AFC与综合监控数据的互联互通，为国内在建的同类型延长线接入工程提出了建设性的思路。

延长线是在已开通运营一段时间后的既有线路基础上，为了拓展线网运营需要，沿用原线路系统设计，新增数个车站，保持统一软硬件设备、数据传输机制及接口规范的延长线路。

延长线新建的4个车站的上层中央计算机系统与一期工程17个车站都使用原中央计算机系统，与综合监控系统的数据传输也通过中央计算机系统中服务器相连，并通过同一小清分系统实现对一卡通及1号线 AFC系统的数据交互。

延长线与新开线路的基本调试方法相同。由于2号线一期工程已开通运营，为保证一期工程 AFC系统的正常运行，在进行延长线的数据信息接入及与ISCS互联互通的调试过程中，应尽可能采用与一期工程一致的软件平台，减少对一期工程既有系统运行的影响和干扰，实现延长线的平滑接入。但是，因为AFC系统工程调试期接近开通期等因素，使其在与ISCS的综合联调配合上存在问题。

为在延长线纳入时不影响一期AFC的运行，实现平稳过渡，需在CC增加一台冗余服务器，实现对CC服务器的改造。此套冗余服务器仅在系统联调期间做测试使用，系统正式运行后将撤离。CC服务器的改造方案中，该实时服务器应采用“类似集群”的架构，即采用由多台服务器共同协作运行的服务群组。新增2台互为冗余的实时服务器将延长线各车站接入，并将延长线所有数据存储于新增的磁盘阵列中。新增实时服务器和原2号线中央服务器在控制中心并列运行。在对新增服务器和接入的延长线数据进行测试和联调的初期，两段线路通过中央交换机的软件设置形成物理上的隔离（防火墙），延长线系统的调试不会对原2号线服务器的数据流向产生任何影响，2号线的ISCS仍维持原系统的稳定运行。