引入接口中间件的基于通信的列车控制系统仿真＊

朱 麟 徐中伟 喻 钢 朱 龙

（同济大学电子与信息工程学院，201804，上海∥第一作者，硕士研究生）

基于通信的列车控制（Communications－Based Train Control，简为CBTC）系统包含了大量厚重的信息资源，以及各种监控数据、庞大的通信网络、各种数据库系统。然而，由于这些系统建设和实施数据管理系统的阶段性、技术性以及其他因素的影响，导致大量数据的存贮方式不同，各系统自成体系、各自为政，无法实现系统间信息的交互和融合，形成了一个个的信息孤岛。解决各系统间信息的有效、可靠、实时通信，成为CBTC系统需要解决的重要问题之一。

早期的CBTC接口仿真系统采用统一的接口规范来约束各子系统的信息格式。这在一定程度上虽然解决了CBTC各子系统信息聚合与交互问题，但由于CBTC系统自身庞大的信息体系，各子系统需要添加自身冗余信息接口庞大，无形中增加了CBTC系统的复杂程度和消耗。此外，由于子系统需要花费冗余的时间对传递的信息进行格式转换，降低了信息交互的可靠性和有效性，很难真正实现CBTC系统各子系统间信息的无缝传递，降低了系统传递消息的效率，额外增加系统的负担。

针对CBTC接口仿真系统现存的信息交互的问题以及如何有效地解决上述问题，提出一种新的接口信息传递模式——接口中间件。接口中间件技术是建立在分布对象中间件（Distributed Object Middleware）的基本架构上，提出适合CBTC系统接口信息交互的异步通信模式：通信双方并不直接交互，而是基于代理（中间件）对象进行交互，接口中间件负责对所要传递的信息进行格式统一，协议转换，旨在解决在分布式异构网络环境下信息系统集成的异构性、可重用性、互操作性问题［3］。

1 接口中间件技术

接口中间件采用分布式对象中间件基本架构，其核心是对象请求代理。它的作用在于提供一个通信框架，透明地在异构的分布计算环境中传递对象请求。对象请求代理是对象总线，它定义了异构环境下对象透明地发送请求和接收响应的基本机制。对象请求代理使对象可以透明地向其他对象发出请求或接受其他对象（这些对象可以既位于本地也可以位于远程机器上）的响应，并且拦截请求调用，负责找到可以实现请求的对象、传送参数、调用相应的方法、返回结果等。客户对象并不知道同服务器对象通信、激活或存储服务器对象的机制，也不必知道服务器对象位于何处、它是用何种语言实现的、使用什么操作系统或其它不属于对象接口的系统成分，这些工作由对象请求代理透明地完成［1］。

分布式体系结构能够很好地将分布式对象技术和网络结合起来，使得应用跨越不同的网络体系结构、不同的操作系统，不同的编程语言进行相互通信，使网络的“互连”特性真正成为现实［2］。

1.1 接口中间件对象与接口定义语言

中间件对象是能够放在忘了任何位置的智能实体。它们包装成二进制组件，可以通过方法调用来访问这些组件。用来创建服务器对象的语言和编译器都对客户完全透明。客户不需要知道分布式对象驻留在何处或者运行在什么操作系统上，它可以是在同一进程中，或者位于网络中的某台机器上。并且客户不需要知道服务器对象是如何实现的。

支持中间件对象的关键技术是接口定义语言（IDL）方法。中间件采用IDL合同来规定一个组件的边界以及它与潜在客户的合同接口。中间件接口定义是定义语言而非编程语言，它纯粹是说明性的。这意味着它没有提供任何实现细节，只能用来定义接口和数据结构。程序员可以用本机语言生成系统处理中间件对象，IDL向驻留在中间件总线上的所有服务器和组件提供了与操作系统和程序设计语言无关的接口，它允许用不同程序设计语言编写的客户机和服务器对象能够操作。中间件将接口与实现分开，提供了中性语言的数据类型，从而使跨语言和操作系统边界调用对象成为可能［1］。

1.2 接口中间件体系结构

接口中间件主要由三部分组成（见图1）：事件请求部分，事件响应部分和对象请求中介（ORB）。对象请求中介即对象总线，通过它，各个对象可以透明地向本地或远端的其他对象发出事件请求／接收事件响应。客户并不知道联系、激活或存储对象的具体机制，这些工作都由对象请求中介来完成，它是在对象之间建立请求或响应关系。通过对象请求中介，事件请求对象可以调用事件响应对象上的方法，这个事件响应对象可以在同一机器上，也可以在网络的另一边。对象请求中介负责寻找可以执行该请求的对象，传递参数，调用方法，最后返回处理结果。事件请求对象不需要知道对象的位置、程序设计语言、操作系统或不属于对象接口的任何其他系统特征。与传统的客户机／服务器系统不同的是，对象请求中介上的对象关系是不确定的，它既可以作为客户来发出事件请求，也可以作为服务器来进行事件响应，使系统结构灵活，功能强大。

图1 接口中间件系统图

接口中间件屏蔽了客户机／服务器实现细节，以事件请求和事件响应来区分所需操作的对象，减轻了用户的负担，将所需要的工作交给对象请求中介来做，使系统流程更清晰，增加了系统消息处理与聚合的可靠性与有效性。

2 CBTC接口仿真系统设计

2.1 CBTC系统及接口仿真概况

CBTC系统是一个庞大的系统，它打破了传统基于轨道电路列车控制系统的限制，提高轨道运输基础设施的使用效率，使用轨旁以及车载关键处理器处理列车状态数据和控制数据，提供连续的列车自动防护，列车自动运行以及列车自动监督功能。CBTC系统的整体架构如图2，主要由轨旁运行控制系统和车载子系统这两个集成的子系统构成，此外还包括各类需要进行信息交互的其他控制系统如联锁、站台信息系统、ATS（列车自动运行监控）系统等等。这里以轨旁运行控制系统为研究对象。全文中所提的CBTC接口系统，即为与轨旁运行控制系统以及与之相关的部分。

CBTC系统在打破原有运控系统架构的同时，带来的却是系统的安全隐患。虽然系统控制人员对CBTC系统各个环节都给予了足够的重视，但是数据传递的滞后和信息的不透明依然存在。系统繁杂的信息交互主要存在于其接口系统。轨旁运控系统需要对轨道线路上的各种信息进行采集和处理，并将信息及时地反应给车载与列车控制中心。应答器、计轴、信号机、道岔等设备之间繁杂的交互信息需要由轨道旁路实时地反映给轨道旁路运控系统。系统应用框架如图2。

图2 系统应用框架

轨旁运行控制系统作为核心系统，需要与其他系统有实时的信息交互，包括与联锁系统设备单元状态信息，外部数字输入单元状态，与ATS系统之间有关临时限速TSR和跳停信息的交互，也包括单元信息的交互，与站台系统之间有关紧急停车按钮EMP（紧急停车按钮）、PSD（站台屏蔽门）信息的交互，与中央服务和诊断系统之间的关于诊断和故障的信息等等。轨旁运行控制系统需要对上述信息进行处理并将其分类存储，当其他系统需要对其中信息发出请求时，再转发给该系统。这样的系统结构与信息处理方式无疑加大了轨旁运行控制系统自身的负担，也不利于各CBTC系统间信息的交互。

引入接口中间件，将轨旁运行控制系统与联锁、ATS、轨旁服务与诊断等系统进行的交互信息一并交给接口中间件处理，由其负责处理CBTC系统各部分对信息的请求与响应，统一对信息结构和类型进行转换以及相应的逻辑处理，使系统各部分无需考虑信息传递的结构、传递方式等各方面的因素。对信息进行模块化的处理，减少了系统内的冗余代码和信息处理的时间损耗，以及各系统自身负担，提高信息采集的准确性，以及信息处理的实时性［4］。

2.2 CBTC接口仿真设计

在引入接口中间件之后，CBTC接口仿真系统可分为三层：轨旁控制管理层（轨旁运行控制系统），基于接口中间件的分布对象中间件层和设备控制层。轨旁控制管理层负责向接口中间件提出信息请求，并等待接口中间件反馈自身所需的信息；设备控制层则是将底层各应用设备的实时数据传输给中间件，并对底层各种设备进行总控。

接口中间件位于轨旁控制管理层和设备控制层之间。对轨旁控制管理层来说，接口中间件通过ORB接口和IDL桩接收来自轨旁控制系统所需信息的请求。这里不涉及控制器种类、现场总线和通信协议不同的影响，这使得轨旁控制管理应用与管理层通信模块相互透明，功能相互独立。对设备控制层来说，接口中间件通过ORB接口和对象适配器与其他各种类控制器交换数据，这很自然地屏蔽了分布式环境中各种网络协议、硬件体系结构、操作系统、数据库等方面的差异性，在异构环境中实现对象互操作，并协调操作的一致性和完整性。其系统架构如图3。

图3 接口仿真系统框架

从图3可以看出，系统还具有良好的扩展性。当设备控制层增加设备时，只需在接口中间件中配置新的对象参数；当管理层增加应用时，只需在IDL桩中添加合适的订阅记录即可，轨旁运行控制系统无需添加冗余的代码对所添加的新设备进行实时数据的采集。

2.3 CBTC接口仿真实现

在系统中，接口中间件负责对数据进行采集与处理，因此负责与外部设备信息交互的IDL接口定义尤为重要。IDL不是编程语言，只能用来定义接口，而不是去实现某个接口。此外，IDL独立于任何编程语言，但可以将它映射为其他常用的语言：IDL编译器将服务对象（轨旁运行控制系统和设备控制层）接口的请求IDL消息转换为具体实现语言的码根和框架。码根为接口中的每一个操作（方法）提供一种虚实现，它负责将编程语言转化为IDL描述语言，发送到对象服务端，并对对象实现的返回进行解码，将处理结果（消息信息）或异常信息反馈出来；框架则是提供了一个为指定的接口编写即对象实现代码的框架，对系统请求进行解码，定位符合要求的对象，并将执行结果或异常信息进行解码后返回系统。轨道旁路设备管理层通过接口中的请求消息事件创建一个请求事件，在这个调用请求中包含目标对象引用、方法名、参数表，所需信息等等。设备控制层则通过IDL接口提供对象方法的实现及返回结果。

简单的IDL接口原理如图4所示。

图4 系统IDL接口原理图

事件响应端支持事件通知和使能事件两个接口，而事件请求端有请求事件消息接口。事件响应端和事件请求端都应支持建立连接和断开连接的操作。事件请求端应支持事件传递时的属性通用事件头，如事件标志、类型名称、事件源标志；另外，这个接口允许（事件体中）附带一个参数快速地传给指定的事件。如果应用中需要传递更多的参数，应该定义一个新的接口并继承这个父接口。

因此，根据分布对象中间件接口的标准定义，CBTC系统仿真接口定义如下：

上述定义中，EventContent定义了事件的结构，它由事件号以及事件所属类型和时间来源三部分组成。EventRequest接口定义了事件请求和事件发布两个接口。其中事件请求接口中包括事件请求函数和事件请求退出函数，当事件请求者需要访问某数据时，它通过事件请求函数向中间件提出申请，当获得相应的信息时调用自身退出函数关闭自身请求。EventBrocase接口是由对象注册和对象注销两个函数构成，事件请求者在请求之前需要向中间件进行使能注册，得到中间件的认可后方可对中间件包含的各类信息进行访问。这样做提高了整个系统的安全性，能够防止其他无权事件请求者的恶意访问。

在本系统中，一个事件请求者（轨旁运行控制系统）和一个事件提供者（设备控制端）无须保持联系，彼此是匿名的，它们只需与处于它们之间的分布式对象中间件保持联系。通过合适的通信安全协议，如一个可靠的多播协议等，它们与中间件进行信息事件请求和响应，这样不仅解耦了通信双方，还大大提高了匹配速度。另外，中间件的过滤器可以合并和删除冗余的请求条件，使中间件的效率提高。

在通信系统中，一个事件提供者需要分布对象中间件来发布事件，一个事件发布的格式是类型名称和属性（参数名称）。一个事件请求者需要找到相应的对象中间件来接收事件。对于标准事件，中间件接口定义如下：

上述定义中，EventReflection接口中定义了新增设备和删减设备的函数，这样方便系统对设备进行管理，也使系统具有相当好的扩展性，方便系统操作。Pxy接口中继承了EventRequest和EventBrocast这两个接口，并新增了一个返回值为布尔类型的查找函数，使中间件能够系统地对自身所存储的信息进行管理。

2.4 CBTC接口仿真系统应用实例

CBTC系统正常运行时，轨旁运行控制系统向中间件提出请求，要求获得轨道上各类信息（信号机、道岔、轨道等）；分布对象中间件收到请求经过验证后，根据请求在自身的存储器中搜索相应的信息，搜到后反馈给轨旁运行控制系统；轨旁运行控制系统将接收到的信息加以处理后显示在自身的界面显示上，如图5。

图5 轨旁运行控制系统设备信息显示界面

设备控制层则是实时将自身的数据反馈给中间件，实现数据的实时更新。以设备状态为例，设备的状态是由一个或多个二进制码表示的，如图6所示。

3 结语

分布式对象中间件在CBTC接口仿真系统的应用研究是一个全新的课题，是实现接口数据传输有效性、通用性、实时性的重要实现方式之一。

CBTC系统间的大量厚重的相互通信的各类信息资源、各种监控数据和各种系统数据，可由分布中间件集中处理。而分布式对象中间件是位于硬件、操作系统平台和应用程序之间的通用服务系统，可实现不同硬件和操作系统平台上的数据共享和应用互操作。利用此技术可为CBTC系统信息交互问题开辟新的思路，从理论上完美地解决CBTC系统中的问题，根本上改变了轨道交通运行控制的运作模式，大幅度提高了系统的效率，具有很好的发展前景，以及很好的可行性和实际应用性。

［1］潘浩.分布式对象中间件结构与性能的研究［D］.河北：河北燕山大学，2001.

［2］吴泉源，贾焰，周斌.分布对象中间件Starbus［J］.计算机工程与应用，2002，16（3）：195.

［3］梅宏.软件中间件技术现状及发展［D］.北京：北京大学信息科学技术学院软件研究所，2004.

［4］闫晓芬，郭银章.基于P／S模式的分布对象中间件异步通信接口［J］.计算机工程，2009，6（3）：125.

［5］符春，缪力，徐艺.中间件技术在汽车客运联网售票系统中的应用［J］.电脑知识与技术，2010，6（2）：1219.

［6］蔡增玉，甘勇.一种基于中间件的可信软件保护模型［J］.计算机应用与软件，2010，27（3）：71.

［7］Marko C，Mavko B.A dynamic fault tree［J］.Reliability Engineering and System Safety，2002，75（1）：83.