王 森 黄友能, 王 伟
(1.北京交通大学电子信息工程学院 北京 100044;2.北京交通大学城市轨道交通自动化与控制北京市重点实验室 北京 100044;3.北京交通大学轨道交通运行控制系统国家工程研究中心 北京 100044)
近年来,随着城市规模的扩大,人们对轨道交通在安全性、可靠性、运输效率和整体服务质量方面都提出了更为严格的要求。世界各地的轨道交通运营商都希望以最少的投资获得更好的性能,以应对现代运输业的各种挑战。基于通信的列车运行控制系统(communication based train control system,CBTC),克服了传统轨道交通信号系统基于轨道电路进行车地通信的信息传输量少、固定分区追踪效率低等缺点,采用了基于无线通信的车地通信方式,大大提高了车地通信的容量,真正实现了移动闭塞,缩短了列车追踪间隔,提高了运行效率,它是今后一段时间城市轨道交通列车运行控制系统的首选。
对于CBTC系统来说,系统的安全性与数据的正确性有着非常密切的联系,系统设计经历了系统开发、设计、成熟到再次优化的过程。在城市轨道交通的信号系统设计方面,如果对每条线路都重新进行信号系统开发显然是不现实的,需要耗费大量的人力和财力。因此,代码与数据分离是一种合理的解决方案。当轨道线路不同时,只改变应用数据,在不改变原系统设计的原则基础上,可减少系统开发的生命周期。这样不仅减少了由于不同线路的不同特性而引起的系统集成,而且方便对数据进行管理,增加了数据的可靠性,进而确保整个CBTC系统的功能实现,可真正实现系统之间的互联互通,确保系统的高效率与安全性。
CBTC系统是连续的自动列车控制系统,采用高精度的列车定位,不再依赖轨道电路;使用连续、大容量的车地双向数据通信,车载设备和轨旁设备实现安全功能。一个典型的CBTC系统应当包括列车自动监控系统(automatic train supervision,ATS)、数据库存储单元(database storage unit,DSU)、区域控制器(zone controler,ZC)、计算机联锁(computer interlocking,CI)、车载控制器(vehicle on-board controller,VOBC)和数据通信系统(data communication system,DCS,包括骨干网、网络交换机、无线接入点以及车载移动无线设备),其基本结构如图1所示。
列车自动监控系统(ATS)完成列车运行监控、报警显示、进路排列和运行图的调整等功能。区域控制器(ZC)系统接收列车的位置报告信息,并为列车提供移动授权权限(MA)。数据库存储单元(DSU)系统存储所有的线路数据信息和配置文件信息,依照车载控制器(VOBC)系统与区域控制器(ZC)系统的要求完成线路数据的实时查询和数据更新工作,接收ATS系统的命令,完成动态信息的修改工作。计算机联锁(CI)子系统完成管辖范围内列车进路的办理和取消,以及道岔等设备的采集和相关操作。VOBC系统可以对列车进行定位,向其他系统汇报自己的位置和延伸申请等信息,同时接收ZC发送的MA,并对列车进行安全控制。数据通信系统(DCS)实现CBTC系统的每个子系统之间的数据传输。
图1 CBTC系统结构
基于计算机的系统十分常见,这些系统通常需要一个灵活的数据驱动,即利用数据对子系统进行配置,以完成系统功能。对于数据驱动系统来说,保证数据的有效性与保证编码的有效性同样重要。数据作为信息的载体,通常与系统应用同时开发,如果数据没有与系统严格一致且失去完整性,就很可能造成系统的崩溃。
CBTC系统是一个保证列车安全运行的系统,因此保证各个子系统的安全性与正确性是十分必要的。CBTC系统按照代码和数据分离的原则,将自身及其子系统的所有使用数据分离出来,与CBTC各子系统运用结合来实现各子系统的功能。数据作为信息的载体,是CBTC系统的基础,为CBTC的所有子系统所共享,其正确性关系到这些子系统能否正常运行。
数据与CBTC各个子系统存在关系:一方面,体现在系统的数据支持,数据与应用程序一起共同完成系统功能;另一方面,体现在系统间进行的数据交换,如区域控制器与相邻区域控制器的数据交换、车载控制器与相关联的车载控制器的数据交换、中心ATS与车站ATS的数据交换。最后,对于一些动态数据和线路数据,各子系统之间还会实现数据的同步与共享。例如,轨旁电子单元 (lineside electronic unit,LEU)接收列控中心传送的数据报文,并发送给有源应答器。数据与CBTC系统各个子系统的关系如图2所示。
图2 数据与CBTC各个子系统的关系
根据CBTC系统原理,为了确保列车的安全运行,使CBTC系统根据需要做出应答,保证系统功能正确,必须给系统提供需要的静态地理信息数据和动态信息数据。为了使列车运行时CBTC系统可以根据实际需求做出正确的反应和应答,必须有来自轨旁的信息。列车需要获取这些数据,才可保证在合理的环境中和合理的条件下安全运行。
CBTC系统应具备如下静态数据:线路区段位置、连接关系信息、障碍物位置信息、坡度信息、停车点及停车区域信息、静态限速信息、折返区段信息、列车参数信息。CBTC系统各个子系统根据各自的原理,调用这些数据至各自的应用程序。数据在系统之间完成交换和转移,系统的安全取决于这些实际交换数据的正确性和完整性。
一旦了解了系统的初始需求,就应该定义数据的管理过程,从各种数据源中获取数据,为应用程序合适地准备并处理数据,最后将数据传递给操作系统。为此,定义了数据供应链,运用数据供应链对CBTC系统数据进行管理。针对不同的CBTC系统,数据供应链的具体表现方式可能有所不同,典型的数据供应链如图3所示。
实线表示的是数据供应链的具体流程,虚线表示的是线条起始端对线条终点端的要求。非常细致的数据供应链并没有描绘出来,因为任何数据管理过程的开发都要考虑不同组织和个人的性质。举例来说,有些组织会喜欢使用适当的工具来获得较好的数据完整性,而其他组织可能更喜欢依赖小规模、有经验的工程师。
一般认为,将大部分不确定性引进数据供应链(DSC)的阶段是最初的数据捕获阶段,这有两个主要的原因:
图3 数据供应链
1)数据记录通常基于文档,所以这项工作是劳力密集型的工作。独立的人工互查能够及时发现数据中的错误,如在检查线路梯度数据的连续性时,具体方法有:通过来源记录,检查进入DSC的数据;通过数据要求以及应用程序规则,检查进入DSC的数据;等等。
2)现有的数据记录永远无法精确地描述基础设施的目前状态,而比较数据的来源能增加识别错误的可能性。从不同的来源获得相同的数值可以提高数据的置信度,但假如随着基础设施改变而数据来源都未更新,则系统容易受到一般问题的影响。附加措施要求对实际基础设施的可用数据进行确认,根据数据要求,数据确认能以很多方式完成。
在DSC内部,需要考虑检验和确认的扩展,常规规则和相应的引导说明有:
1)在生命周期中,较早修复错误最划算;
2)在生命周期中的早期阶段,发现所有的错误是不可能的,因此在DSC中的后半部分要有附加的测试;
3)要防止数据通过DSC退化,最佳途径是使用合适的配置管理和质量管理;
4)阻止错误进入DSC比稍后清除它们成本要低,因此要使用高可靠性的工具完善数据入口,使数据入口更安全便利;
5)正式的数据结构规范可以减少错误发生的几率,而且按照正式规范开发和使用工具还会减少故障的发生;
6)验证的目的是检查数据是否保持原意,要确定数据没有发生歧义;
7)通知管理数据的人明白数据的重要性,使他们集中注意力,并充满责任感;
8)仔细考虑工具的多样性和数据的高度完整性;
9)利用像MD5(message-digest algorithm 5,信息-摘要算法5)、CRC(cyclical redundancy check,循环冗余码校验)和其他哈希算法这样的技术来检测损坏的数据;
10)提高由DSC所提供数据的置信度,这能减少安全隐患和操作风险。
CBTC开发单位可以为不同完整性需求的数据项目开发单一的DSC,而能否这样做则依赖于开发过程中的自动化程度,以及高完整性数据与低完整性数据间的比率。
4.3.1 确定数据源头
这是数据供应链的开始阶段,作为一般性规则,可以把第一个阶段定义成接受阶段。后面的阶段会存储并使用已知完整性的数据,若在数据完整性中要求较高的置信度,则可以通过测试、分析和必要的仿真获得。
4.3.2 确定边界
一个CBTC项目可能由几个不同的单位共同完成,那么各个单位责任的改变就要求数据供应链确定边界(组织的、法律的、政治的),并创建合适的连接部分。作为一般性规则,挑选、设计数据版式阶段和分配数据阶段用来创建这个连接部分。这个部分的另一边是接受阶段,交换数据时不需要是实体的连接,重要的是要确定相关责任和可能出现的所有权变更。
4.3.3 确定处理和改编
这一步要确定重要的接口,完成数据的处理和数据集的改编,由集合、翻译、挑选以及转化阶段组成。
4.3.4 分配完整性需求
对数据的完整性需求进行详细说明,将这些需求在数据源和数据供应链各阶段之间进行分配。
4.3.5 确定证据需求
确定每个阶段的核查标准,在数据源与数据供应链各阶段之间分配了完整性需求后,就可以为数据源和数据供应链各阶段建立证据需求,这样可以保证模型的有效性和完整性。
4.3.6 指定校正过程
如果数据没有满足各个阶段的验证标准,系统将会报错,这就要采取纠正措施。这个过程完成各个DSC阶段的校正,并对整体上的数据供应链进行纠正。
4.3.7 评估数据供应链设计
要满足安全苛求系统的5个基本安全目标,即需求有效性、需求满意度、可追溯性、配置一致性和互不干扰安全的功能。
在数据供应链的设计过程中,必要时可以重复上述步骤来完成设计的目标,即完整的组织责任、负债和所有权。数据起源可能是最困难的议题,这涉及设计、开发、数据提供和数据驱动系统的维护。足够完整(足够满足所有使用数据的系统要求)的数据产生有许多形式,传统的是根据录入到表单中的数据项是纸张记录还是电脑屏幕上的自动显示来判断。随着CBTC系统的规模扩大,数据的容量和性质也需要改变。数据产生需要纵向的数据集,它描述基础设施和控制基础设施使用的抽象层。在系统相互配合的地方,这些数据集被看作是整个系统结构中的横向部分,横向数据集可以通过扩展现有数据集来延长控制范围,以便描述更大的地理区域。
1)对数据的安全完整性水平(SIL)的分配应该建立在详细的风险评估基础上,整个系统的SIL不能完全确定数据的SIL。对于操作数据,考虑到涉及的时间约束和如果不能快速改变数据而引起的风险,风险评估就必须考虑合理、可行的方案。
2)数据供应过程的开发应该注意,要在过程中尽早地识别和修复错误。尽量在测试时更正错误,因为到了系统安装期间就很难发现错误。
3)数据和系统会随着时间而改变,因此在整个数据生命周期中,数据管理过程的设计都应该使用严格的结构管理,从而提高数据的置信度。当轨道交通信号系统组件更新时,要减少重复昂贵的数据采集和验证。
4)初期的识别数据需求和安全目标,决定了数据供应链的设计。
5)充分考虑整个数据生命周期,要有适当的过程和措施开发,以便维护需要的整体性,确保在正常和被降级情况下的安全操作。
6)数据准备的过程和软件开发的过程相似,在完整定义的过程中,使用工具检查和人工复查相结合的方法来获得完整性。
为安全苛求系统开发数据管理过程是一项有意义的工作,而且经常是在系统开发早期阶段被忽视的过程。在本研究中,强调了许多使用CBTC所经历的问题,并提出一个数据供应链的设计和构造方法;使用这个方法,可以有效地进行CBTC数据管理。然而,数据的组织仍是一个艰难的议题,要想获得高完整性的数据需要许多不同的资源,需要相互比较来提升检错的几率,这就要求更多的组织机构和科研人员共同合作。
[1]IEC 61508 Functional safety of electrical/electronic/programmable electronic safety -related systems[S].London:IEC,1998.
[2]EN50128:2001 Railway applications:communications,signalling and processing systems:Software for railway control and protection systems[S].London:CENELEC,2001.
[3]RTCA/DO178-B Software considerations in airborne systems and equipment certification[S].London,1992.
[4]Defence Standard 00-55 Requirements for safety related software in defence equipment[S].London:UK Ministry of Defence,1997.
[5]Storey N,Faulkner A.The role of data in safety-related systems[C]//Proc.19th International System Safety Conference.Huntsville,2001.
[6]Storey N,Faulkner A.Data management in safety-related systems[C]//Proc.20th International System Safety Conference.Denver,2002.
[7]Storey N,Faulkner A.The Characteristics of data in dataintensive safety-related systems[C]//22nd Int.Conf.on Computer Safety and Reliability,Safe comp 2003.Edinburgh,2003:396-409.