验证是指对系统或产品评价的过程，以确定一个给定阶段的输出是否满足该阶段开始时所给定的要求。
对于自动列车监控系统（ATS）来说，验证活动是一个庞大的工程，在产品需求分析、设计开发及测试的各个阶段，都应执行充分的验证活动。
ATS系统的最高安全完善度（SIL）等级被定义为2级，因此应按照SIL2的标准对ATS系统进行验证活动。
本文致力于阐述ATS系统生命周期中的验证过程，对验证活动进行简要说明。而信号系统的生命周期，通常采用V模型。
（一）ATS系统概述
自动列车监控系统（ATS）是列车自动控制系统（ATC）的重要子系统之一，是一套提供给运营调度人员进行在线监测行车状态，进行自动控制和人工干预的一套信号系统。
一方面，通过其它信号系统，ATS获得现场信号设备和列车运行的实时状态信息，并把这些信息如实地展示给调度人员进行监视。
另一方面，ATS还提供了人机交互界面，方便调度人员根据现场情况实时进行人工干预；此外，还根据不同的运营模式，提供自动化的控制手段，以减轻运营调度人员的作业负担，提高轨道运输的效率和服务水平。
其主要功能包括：
站场信息显示
信号控制
列车追踪和控制
控制区域管理
运行图管理
报警/日志管理
其他辅助功能
（二）需求分析阶段验证
好的基础便是成功了一半，验证活动首先要保证需求的正确性和完备性。验证需求的正确性通常采用的方法是标杆比对、专家评审和检查表。
（1）标杆比对
通常信号系统的需求来自于国际国内的行业标准，以及运营的特殊要求。标杆比对则是将提取到需求与行业标准、业内先进经验进行比较，从而分析出遗漏与不足，改进自身需求的过程。
ATS系统需求获取主要参考以下ATS相关标准：
1、GB地铁设计规范
2、GB/T-城市轨道交通信号系统通用技术条件
3、IEEEStd..1-,IEEE基于通信的列车控制(CBTC)系统的性能和功能要求
在年中国城市轨道交通轨道技术装备专业委员会发布了《城市轨道交通CBTC信号系统-ATS子系统规范》，作为归纳总结后的需求规范，可作为重要的参考。
由于ATS系统直接提供给调度人员直观的人机交互界面，因此，不同的运营单位常常会有不同的需求。
举个最简单的例子，北京地铁7号线有地上地下车站，则要求ATS系统在站场显示时，提供地标显示，用以区别地上、地下或高架。而北京地铁2号线只存在一种地形，都是地下，则不需要此类数据。
因此，在验证需求时，不仅需要参考标准，还需要参考合同文件及其他附属技术联络会议纪要等，根据实际情况进行调整，以满足特定用户的要求。
（2）专家评审
专家评审是保障需求正确性的重要手段。在产品需求经过内部评审后正式定稿前，验证人员应组织专家评审，对需求进行二次检查。专家评审通常以会议的形式进行，邀请行业专家参会评审。
可以事先将相关材料发放给专家，也可以在会上采取头脑风暴的方法进行专家提问。专家评审会应邀请业内专家、运营调度人员或客户代表，项目经理、产品经理、验证和确认人员。而这个过程中，产品经理应起主导作用，阐述产品需求、记录专家评审意见、进行解释说明，进行整改记录，获取专家认可。专家评审会最终应达成专家评审意见，获取专家对需求的认可，并进行签字确认。
（3）检查表
在EN表E9中，SIL2级的产品强烈推荐使用检查表的方式进行验证。因此不仅是在产品需求中，在产品生命周期的所有的产品文档都应进行文档检查。通常在企业标准中，会制定相应的检查表，进行检查。以下以产品需求为例，说明检查的内容。
产品需求的检查项，包括且不限于：
清晰性：
是否存在有理解分歧的需求?
需求是明确，准确和清晰的吗?
是否每个需求都是切实可行的?
追溯性：
需求是可跟踪的吗？
完整性：
是否所有的需求都被完整的定义了?
是否包括了与功能性相关的所有需求?
是否包括了与性能相关的所有需求?
是否包括了与外部接口相关的所有需求?
是否包括了与数据库相关的所有需求?
是否包括了与硬件相关的所有需求?
……
在《软件验证与确认》一书中罗列出一些产品文档检查表的模板，可用于设计检查表时借鉴和参考。
（三）设计开发阶段验证
