基于AUML的列控系统运营场景多智能体建模仿真研究

李 亚,张亚东,郭 进,周 慧

(西南交通大学信息科学与技术学院,成都 611756)

列控系统是保证列车运行安全的分布式实时控制系统[1]。采用建模仿真的方法对其进行研究分析能够减少列控系统现场测试成本，提高测试效率，对不断完善列控系统具有重要意义[2-3]。同时通过仿真系统能够验证现场不易测试的情况，对列控系统安全性的研究具有重要的应用价值。随着列控系统的不断发展，列控系统具有了交互性、混合性、反应性和并发性的复杂特性[4-5]。研究一种有效并满足列控系统复杂特性的建模仿真方法，能够为列控系统的研究提供高效全面的仿真环境支撑，为列控系统的研究奠定重要基础。

基于Agent的多智能体方法是研究分布式复杂系统的前沿技术，为实现分布式复杂系统提供了一种有效的途径[6-7]。目前列控系统已应用了多智能体仿真，如文献[8]对CTCS-4级列控系统进行多智能体仿真，文献[9]对RBC切换场景进行多智能体仿真，文献[10]对列控系统中列车追踪运行进行多智能体仿真，文献[11]对列控监控系统进行多智能体仿真，文献[12]建立多智能体调度员训练模拟器。但文献[8-9]采用的是面向对象的建模方式，文献[10-12]只是使用了多智能体理论，未使用基于Agent的多智能体建模方法进行模型构建。

多智能体的建模方法是基于Agent对系统进行模型构建，能够简化建模过程[13]。目前已发展出多种建模方式[14]，其中以UML2.0扩展的基于Agent的AUML统一规范建模语言[15-16]，因UML的广泛应用具有很大的优势，利用该优势，使得在应用AUML构建多智能体模型时，有着很好的基础。

因此，本文研究基于AUML对列控系统运营场景构建多智能体模型的方法，最后以RBC切换场景为例，展示该方法的应用过程，并结合模型和多智能体仿真平台进行仿真。

1 多智能体和AUML

1.1 多智能体建模理论

多智能体因其具有的自主性、灵活性、可扩展性和交互协作等特性，使其成为一种能够很好体现复杂系统特性的建模仿真方式[17-18]。它通过一种自低向上的建模仿真方式对系统进行分析设计[19]。其建模过程分为如下步骤。

(1)系统的界定和描述：在对一个系统进行分析设计时，首先应明确该系统的功能目标，界定系统的边界。

(2)个体Agent的划分：采用面向Agent的方法，从系统的物理实体或者系统的功能出发，抽象出系统的Agent。

(3)个体Agent的建模：抽象出个体Agent模型后，便是对系统的每个Agent进行详细的内部结构设计。

(4)建立宏观模型：根据已有的Agent模型，建立Agent之间的交互，确定系统的宏观模型。

1.2 AUML建模技术

AUML与UML均采用图形的建模方式，目前在UML的基础上扩展研究了AUML的交互图和类图。AUML的交互图通过如图1所示的3种交互协议连接符来增加Agent交互间的并发机制。同时，通过在交互图中添加嵌套或交叉协议来促进模型的可重用性。嵌套协议经常被用来定义一个循环。

图1 AUML交互协议连接符

图中“与”表示消息并行发送，“或”表示不发送或发送其中几条消息，“异或”则表示只发送其中一条消息。

AUML的类图在UML类图的基础上发展成如图2所示的Agent类图。

图2 Agent类图

本文使用的Agent类图只包含Agent名称、状态描述、行为和方法。Agent名称定义Agent的名，区分模型中的各个Agent。状态描述与UML类图的属性类似，用于Agent的逻辑描述。行为是指被Agent本身触发或接收了其他Agent发送的消息被触发时产生的行为。方法是实现Agent行为的操作。

2 列控系统运营场景多智能体建模方法

结合多智能体构建模型的方法和列控系统相关技术规范，在对列控系统运营场景采用AUML进行多智能体模型构建时，分为4个步骤如图3所示。

图3 列控系统运营场景构建模型结构

2.1 系统功能需求用例图建模

系统功能需求即是明确系统的目标。确定系统实现哪些功能，各种功能之间存在的关系，构建系统用例图来表示系统的功能目标。从高铁列控系统相关技术规范中对列控系统运营场景过程的描述，可以明确系统在实现某个运营场景时系统所需功能，如车载的通信功能、RBC的切换功能、列控中心的轨道占用检查功能等。

2.2 抽象Agent定义类图建模

明确系统功能需求后，从系统的物理实体出发，通过系统的功能需求描述来抽象出Agent，从而确定每个Agent所处的状态、行为及实现方法，以此来建立个体Agent的类图。列控系统中的物理实体即是列控系统的组成部分，如应答器、RBC和CTC等。仿真时会通过列车的运行来验证列控系统的运营场景，因此建模时的物理实体应考虑车载和列车。

2.3 Agent信息交互图建模

建立个体Agent的类图后，明确了个体Agent间的关系及其包含的状态、行为，则需通过AUML交互图来定义系统中各Agent间的信息交互顺序。AUML交互图中的对象即是抽象出的个体Agent，并通过时间序列来表示参与交互的Agent间的信息交互顺序。

2.4 Agent内部设计状态图建模

为了更清晰地描述Agent内部的行为状态，通过Agent的定义和Agent的交互构建每个Agent内部的结构模型。Agent定义给出了Agent的状态、行为和方法，而Agent的交互则给出了Agent时间上的逻辑顺序，通过将两者结合构建出Agent在被某个消息事件触发后处于的行为状态图模型。

3 RBC切换场景多智能体模型构建

3.1 RBC切换场景

RBC切换场景是CTCS-3级列控系统的典型运营场景之一，本文选取该场景进行案例分析。RBC切换场景描述的是列车在两个RBC边界处，其行车许可控制从一个RBC安全切换到另一个RBC的过程[20]。在双电台情况下，RBC切换过程如图4所示。

图4 RBC切换示意

(1)RBC切换开始：列车通过RBC预告应答器后，车载发送位置报告给移交RBC，移交RBC在接收到位置报告后，发送RBC切换命令给车载，并将接管列车预告和进路请求发送给接收RBC。接收RBC接到进路请求后，向移交RBC发送进路信息，移交RBC根据进路信息延伸MA。

(2)建立通信：车载接收到RBC切换命令后，开始呼叫接收RBC，接收RBC则返回系统版本，车载向接收RBC发送通信建立信息。

(3)列车通过执行应答器：列车最大前端通过执行应答器后，车载发送位置报告给移交RBC和接收RBC，两个RBC在接收到位置报告后，移交RBC将该报告信息转发给接收RBC，接收RBC则发送接管列车的信息给移交RBC。

(4)RBC切换结束：列车尾部通过执行应答器后，车载发送位置报告给两个RBC，移交RBC接收到位置报告后，开始与车载切断通信，车载保持与接收RBC的通信，并按接收RBC发送的MA监控列车运行，RBC切换结束。

3.2 多智能体模型构建

根据技术规范中RBC切换场景的过程，应用列控系统运营场景AUML建模方法，构建RBC切换场景的多智能体模型。

(1)RBC切换系统功能需求

RBC切换过程中涉及的系统功能主要有RBC的切换功能(RBC Switch)、车载的速度监控(Speed monitor)、车载的通信(Communication)和列车定位(Train position)。移交RBC和接收RBC在切换过程中的切换功能又包含不同的子功能。移交RBC的切换子功能包含RBC切换命令发送(RBC Switch command)、行车许可计算(RBC Generate MA)、移交列车预告(Take over train forenotice)、进路请求(Request route)。接收RBC的切换子功能包含行车许可计算、进路信息(Route message)和接管列车信息(Take over message)。车载速度监控依赖于静态速度曲线计算(Static velocity curve calculation)和动态速度曲线的计算(Dynamic velocity curve calculation)。车载的通信包含呼叫RBC(Call RBC)、建立通信(Build communication)和切断通信(Cut off communication)。列车定位包含接收应答器信息(Balise message)和列车运行位置(Train running)。根据各功能间的包含、依赖和关联关系，建立如图5所示的系统功能需求用例图模型。

图5 RBC切换场景系统功能需求用例

(2)RBC切换抽象Agent定义

完成RBC切换过程主要参与的物理实体有两个RBC、车载、应答器和列车，因此抽象出车载(OBE)、移交RBC(HandRBC)、接收RBC(ReciveRBC)、应答器(Balise)和列车(Train)5个Agent。再根据系统功能需求用例图确定各Agent类图中的状态、行为和方法，设计出如图6所示的Agent类图模型。

图6 RBC切换场景Agent类图

RBC切换场景的Agent类图给出了各Agent间的关系。应答器与车载之间的直接关联关系，表示应答器信息发送给车载。列车与车载之间的依赖关系，表示列车的运行依赖与车载的控制。两个RBC之间的关联关系，表示两个RBC之间存在一定的关联关系，如移交RBC需要发送进路请求给接收RBC，接收RBC需要发送进路信息给移交RBC。

列控系统中Agent的状态描述即是抽象出的Agent的属性变量，如列车的位置和速度、车载的控制策略等。Agent的行为表示系统中Agent的可能操作行为，如列车的运行和停车、车载的控车等。Agent的实现方法表示Agent实现操作的具体方法，如实现列车运行和停车需根据接收车载发送的信息和牵引计算更新列车的位置和速度。

(3)RBC切换Agent信息交互

Agent类图抽象出的Balise、HandRBC、OBE、ReciveRBC和Train 5个Agent作为交互图中的对象，按照实现场景的时间逻辑顺序建立如图7所示的RBC切换场景Agent交互图。

图7 RBC切换场景Agent交互

Train和OBE两个Agent之间在RBC切换的整个过程中的信息交互是一直循环存在的，因此使用嵌套协议的方式将其定义在RBC切换场景交互图中。

(4)RBC切换Agent内部设计

RBC切换过程定义了5个Agent，这里以RBC切换过程中移交RBCAgent的状态图模型进行说明，如图8所示。移交RBC的初始状态是ControlOBE，即根据线路情况计算行车许可CountMA()，发送给车载控制列车运行的状态。当列车位置报告Train pass LTA时触发移交RBC的切换状态，该状态下，移交RBC的SendMessage()包括RBC切换命令给车载，移交列车预告信息和进路请求信息给接收RBC。如果移交RBC接收到RouteMessage，则更新发送给车载的MA。当列车位置报告Train head pass RN，移交RBC的SendMessage()为转发的位置报告。当列车位置报告Train tail pass RN，移交RBC执行Stop communication command的命令，当切断通信后，RBC切换结束。

图8 移交RBCAgent状态模型

3.3 RBC切换场景多智能体仿真实现

根据模型，使用MASON多智能体仿真平台，以武广线武汉高速场到龙泉东的线路数据构建仿真的线路环境，进行RBC切换场景多智能体仿真。模型映射到仿真平台时继承的类、接口或使用的方法如表1所示。

表1 模型映射到MASON仿真平台

通过如图9和图10所示的模型监控器与列车运行示意图可以监控RBC切换过程。仿真开始前设置仿真步长StepTime为0.01 s，仿真动态显示与实际长度的比例LengthScale为0.25像素/m。最终通过obe1State实时监控车载与RBC通信情况，HRBCcontrolTrain和RRBCcontrolTrain分别监控移交RBC与接收RBC接管列车情况。图10中的speed与position实时动态显示列车的实际速度与位置。

图9 模型监控器

图 10 列车运行示意

图11所示的系统各Agent运行监控反映了系统每运行一个step时，各Agent是随机顺序执行，以此符合系统的并发性。同时系统通过Network网络的Edge在各个Agent间进行通信，图11反映了Agent接收信息的情况，通过该仿真数据可以得出系统满足RBC切换过程的功能和信息交互，符合系统的交互性。

图11 系统各Agent运行监控

图12反映了系统实时计算连续速度监控曲线的特性，同时能够根据速度监控曲线采取离散的牵引制动，符合系统的混合性。速度监控曲线的计算是车载根据地面设备的行车许可和自身的速度位置计算，并利用该曲线对列车的速度进行监控，符合系统的反应性。

图12 速度监控曲线

4 结语

结合研究分布式复杂系统的多智能体建模理论和AUML建模语言，提出一种基于AUML构建列控系统运营场景多智能体模型的方法。并以RBC切换场景为例,详细描述了应用该方法的建模过程，根据模型设计得到RBC切换场景的多智能体仿真。分析仿真结果，该方法满足了列控系统的并发性、交互性、混合性和反应性，证明了该方法的可行性，为支撑列控系统研究的建模仿真提供了一种更符合其复杂特性的方法。