王 硕,张亚东,郭 进,和贵恒
(西南交通大学信息科学与技术学院,成都 611756)
列车运行控制系统(简称:列控系统)是高速铁路的核心技术装备,在保障行车安全、提高运输效率方面具有重大作用[1]。现代系统安全理论表明,随着系统复杂度与耦合度的不断提高,系统事故的发生往往不是若干危险致因事件简单线性叠加作用的结果,而是由一系列危险致因事件相互作用、相互耦合而导致的。因此,需要对列控系统不同运营场景,特别是复杂运营场景,充分考虑列控系统的各种特性,对其进行建模与仿真,为列控系统复杂运营场景的系统安全分析奠定基础。
目前有很多建模仿真方法应用于列控系统,其中广泛应用的包括UML、Petri网、Scade等。文献[2]利用UML2.0支持的底层语言扩展机制,构建面向列控系统混成特性的建模方法和原型工具。文献[3-4]对UML面向混成性进行扩展,建立运营场景的UML模型,并将其转换为PHAVer模型进行验证。上述方法能够满足列控系统混成性的需求,但没有体现列控系统的交互、并发特性。Petri网是具有严格语法语义的形式化方法,具备强大的数学理论支持,对系统的并发性也有很强的动态分析能力[5]。如文献[6]利用有色Petri网对车载设备RBC切换的两种方式分别建模,模拟在GSM-R网络中消息的传输过程和重发机制[6]。文献[7]采用着色Petri网对RBC与列车之间的无线通信进行研究。文献[8]采用着色Petri网建立了列控中心软件系统层次化模型,并利用状态空间分析方法予以验证。然而,UML与Petri网方法多以状态变迁为重点,对于复杂的列控系统,任何一个场景的状态都呈现“爆炸”的态势,无法准确描述。Scade模型可以转化为具有严格形式化语义的Lustre语言,能够分析分布式系统的并发行为。如文献[9]利用Scade数据流,建立系统功能性体系结构模型和功能故障模型,并将两种模型集成起来进行分析,得到系统的安全关键功能和系统危险源。文献[10]利用Scade对CBI系统进行建模和分析。但文献[9-10]没有提及系统混成性和交互性方面的论述。
Multi-Agent的思想来源于对生物界中群体运动现象的研究,通过功能独立的Agent之间的交互协作,为复杂系统的建模与仿真实现提供了一条崭新的途径[11]。例如,文献[12-13]提出了一种用于危害分析的Multi-Agent建模与仿真方法,并应用在军事对抗复杂系统中,达到了很好的效果[12-13]。近年来,Multi-Agent被引入到列车控制领域,文献[14]建立了基于Multi-Agent的CBTC系统仿真框架,对实体模型和功能模型进行了具体设计并实现仿真。文献[15]利用Multi-Agent理论,建立了一种移动闭塞条件下的多车追踪运行模型,并仿真研究了列车追踪运行的速度和密度问题。文献[16]应用Multi-Agent技术,建立了应急联锁系统的框架,并用C语言编程实现了分布式联锁软件。然而目前Multi-Agent在列车控制领域的应用多与文献[14-16]相似,只是引用了Multi-Agent理论的概念进行模型设计,并没有采用面向Multi-Agent建模的工具和方法,并且在仿真过程中也依然采用传统的面向对象或面向过程的编程方法,没有充分发挥Multi-Agent在描述模拟列控系统特性方面的优势。
因此,本文研究适用于列控系统特性的Multi-Agent建模仿真方法,并提出了基于Multi-Agent的高铁列控系统复杂运营场景建模与仿真方法。该方法采用Multi-Agent理论,将列控系统技术规范与Prometheus建模方法相结合,并利用Multi-Agent仿真工具实现仿真。
Agent目前尚无统一的概念,本文引用如下定义。Agent是位于环境中的,具有自治性、反应性、主动性、灵活性、健壮性、社会性的程序软件[17]。其组成包括感知(Percepts)、动作(Actions)、目标(Goals)、计划(Plans)、事件(Events)、信念(Beliefs)等。其中,感知是通过一些传感器从环境获取信息;动作是Agent做出一些影响环境的行为;目标是Agent主动去实现达成的任务;事件是由感知形成的,需要Agent以某种方式做出反应;信念是Agent关于环境的认识;计划是实现目标的方法;它们之间的相互作用关系如图1所示[17]。
图1 Agent元素间相互作用关系示意
Prometheus方法是比较成熟的面向Agent的软件开发方法,该方法定义了一个详细的过程用来说明、设计、实施、测试面向Agent的软件系统。PDT(Prometheus Design Tool)是支持Prometheus方法的自动化模型设计工具,在应用过程中会产生一系列图形和文本的描述,这些图形和描述均与Agent的元素相对应并作为仿真设计的依据。
Prometheus方法具体包括3个阶段。第一阶段是系统规范阶段,分析确定系统的目标和基本功能,同时确定系统的感知输入及动作输出,该阶段PDT会产生目标概况图模型。第二阶段是结构设计阶段,确定系统中需要几种Agent类型以及它们之间的交互,该阶段PDT会产生系统概况图模型以及交互协议图。第三阶段是详细设计阶段,关注每种Agent内部的逻辑以及在整个系统中如何完成自身的目标,该阶段PDT会产生Agent概况图模型。3个阶段中PDT产生的模型涉及了感知(Percept)、动作(Action)、协议(Protocol)、Agent、目标(Goal)、能力(Capability)、数据(Data)、消息(Message)、计划(Plan)等元素,表示它们的图元如图2所示。
图2 Agent元素图元示意
MASON是Multi-Agent仿真平台,采用结构化程序设计且可充分利用PDT建立的Multi-Agent模型。MASON摆脱了大多数Agent仿真平台都侧重于社会科学领域的缺陷,是通用的Multi-Agent仿真平台。其理念之一是最大化执行速度,能够保证列控系统这类复杂系统仿真模拟的重现。
此外,MASON广泛应用于处理2维空间中连续的群体运动行为,群体运动中涉及了Multi-Agent间的交互、并发、混成等性质,因而能够满足列控系统特性的需求。
列控系统Multi-Agent建模仿真方法框架如图3所示,分为6步。
图3 列控系统Multi-Agent建模仿真方法框架
(1)依据技术规范,选定列控系统的运营场景,确定系统边界,做出合理假设,提取设备主体、功能、交互等相关描述。
(2)确定系统和子系统所需完成的目标以及从环境感知的信息以及作用于环境的动作。
(3)根据系统包含的设备主体,确定Agent类型以及它们之间的交互行为。
(4)对每种Agent类型完成相应目标的计划逻辑进行描述,并对PDT产生的模型进行校验。
(5)根据Multi-Agent模型,利用MASON编程实现仿真。
(6)利用MASON中的监视器,监视各个Agent运行中产生的数据,并以此分析目标实现情况以及对列控系统的适用情况。
对完整的列控系统进行建模仿真,无疑是太过庞大和复杂,难以把握建模仿真的重点。选择典型的运营场景进行研究,既能够较容易地从规范中提取信息,又能够把握建模仿真的重点。同理,一个运营场景要实现其目标需要获取大量的信息,有些信息的产生过程与场景并非紧密相关,因而划定系统边界,令一些信息为外部环境信息(不关注该信息如何产生,只关注该信息对系统目标的作用),进一步简化建模仿真的规模。
经过简化处理后,从规范中提取指定场景涉及的设备主体、功能以及交互的描述,为建模奠定基础。其中设备主体的提取主要确定场景中涉及哪些设备,以文本的方式记录并进行命名,为后续建模抽象Agent类型奠定基础。其次,根据各个设备主体的技术规范提取涉及的功能名称、功能描述及功能执行条件,以功能列表的形式进行记录,为确定Agent目标任务提供依据。最后,各个设备主体之间的关系及交互信息以序列图的形式进行提取,为确定Agent间的交互及系统中各个Agent的关系提供依据。
基于规范中提取的内容,利用Prometheus方法及其支持工具PDT进行Multi-Agent建模。在建模过程中,充分利用从规范中提取的内容,能够简化Prometheus方法中的一些中间步骤,使得构建的模型既来源于规范,又符合Prometheus方法。
首先利用提取的功能描述构建Agent的目标概况图模型。将场景中的系统级功能构建为目标概况图的顶级目标,然后将为了实现系统级功能而必须实现的各个子功能构建为顶目标下的子目标,以此逐层深入直至场景中所有交互的内容都有指定的子目标相对应。
其次构建系统概况图模型,确定Agent类型及Agent类型之间的交互。在确定系统Agent类型过程中,直接根据提取的设备主体进行划分,例如将列车、车载设备、RBC等确定为不同的Agent类型。然后,需要详细描述Agent类型之间以及与环境的交互,并以AUML(Agent UML)符号进行表示。
最后详细设计Agent内部实现其目标的逻辑,构建每个Agent类型的Agent概况图模型。Agent概况图模型表达了Agent内部为实现其目标的输入输出逻辑关系,其中计划是Agent类型中输入输出的逻辑表达,而能力是一组计划的集合。消息和数据则为Agent的输入输出或内部逻辑的中间产物。
至此产生了一些图形化的Multi-Agent模型,图形化模型中的每个元素还全部附有相应的文本描述。其中文本描述主要包括元素的关系和属性两种,关系描述是在建模过程中自动生成的;属性描述由人工完成,是对各元素作用、逻辑、参数、公式等的表达。
模型的校验过程分为两部分,以保证模型的准确性。首先,人工检验规范提取过程中有无遗漏的、错误的功能或交互信息以及Multi-Agent模型是否全部准确描述了这些功能和交互信息。其次,PDT能够自动校验元素的命名、交互协议的完整以及逻辑表达与交互内容的对应。
依据每种Agent类型所需要完成的目标,以Agent概况图设计Agent类型中的变量及函数,根据“计划”描述模型实现具体函数。之后,根据交互协议模型,通过MASON提供的Networks实现信息交互设计。再根据系统概况图模型将环境与Agent关联起来。最后,利用MASON提供的监视器动态监视系统中Agent内部的运行数据,分析列控系统仿真中各个Agent的运行情况。
此外,利用MASON的schedule方式打乱时间步次序,模拟系统中各子系统的并发行为;利用MASON的高质量随机数生成器模拟列控系统中测速定位误差、通信延时误差等不确定因素。
RBC切换是CTCS-3级列控系统14个主要场景之一,描述了在不同RBC边界处,实现列车在两个RBC间行车许可控制的安全切换过程[18]。RBC切换包括两部GSM-R无线电台都正常和只有一部GSM-R无线电台正常的场景,本例研究两部GSM-R无线电台都正常的场景。
本例系统范围界定为包括Train(列车)、OBE(车载设备)、RBCH(移交RBC)、RBCA(接收RBC),设定列车的速度位置作用于环境,联锁信号授权、应答器信息、测速定位数据从环境获取。RBC切换场景部分功能列表举例如表1所示。
表1 RBC切换场景部分功能
文献[18-20]中描述了两部电台都正常的RBC切换流程,并有车地无线通信的消息内容,将其提取为序列图,如图4所示。
依据提取的功能列表建立目标概况模型如图5所示,该图主要以RBC切换和Train监控为两个顶目标,逐层构建各个子系统需要完成的目标。
根据目标概况图模型及系统范围界定建立RBC切换场景的系统概况图模型,如图6所示。该模型表达了RBC切换场景Multi-Agent模型所包含的Agent类型、Agent类型之间的交互关系、与环境之间的作用关系等,是模型中的核心的部分。
两个Agent类型之间交互内容的具体逻辑通过AUML描述,例如RBC切换场景中OBE-Train交互协议的AUML图,如图7所示,OBE从环境获得测速测距信息,经运算判断列车超速情况并下达制动命令;而列车的实际速度位置更新则作用于外部环境。
图4 RBC切换场景序列
图5 RBC切换场景目标概况模型
Agent内部逻辑关系的构建以Trainagent为例,其主要逻辑为根据收到的常用制动命令和紧急制动命令触发相应执行命令计划,从而使速度更新和位置更新作用于环境。Trainagent的Agent概况图模型如图8所示。
图6 RBC切换场景系统概况模型
图7 RBC切换场景OBE-Train交互协议AUML图
图8 Trainagent概况图模型
根据RBC切换Multi-Agent模型,利用MASON仿真平台编程实现仿真。其中,利用模型监视器对Trainagent、OBEagent、RBCHagent、RBCAagent内部交互情况以及列车的实际速度位置、车载获取速度位置的监视情况如图9所示(长度单位:m;时间单位:s)。
图9 RBC切换场景动态运行数据监视
图10 Trainagent与OBEagent的位置走势
图9反映了Trainagent与OBEagent的速度位置随时间的变化以及OBEagent读取应答器校正位置并向RBCH报告位置的交互情况。但由于测速误差的存在Trainagent与OBEagent的速度位置数值并未保持一致,图10监视了二者位置随时间变化的走势,二者位置误差随时间积累越来越大,但在1 000 m附近由于应答器的存在误差几乎消失,模拟了列控系统中的实际运行情形。
Agent的执行顺序是指在系统一个时间周期中,各个Agent的执行顺序,从图11中观察到,各个Agent并不是以固定的时序执行,而是以随机的时序运行。通过此种方式模拟场景各个Agent并发执行的过程,以满足列控系统的并发性。
图11 各个Agent执行顺序
从整个动态仿真数据可以看出,RBC切换场景Multi-Agent仿真实现了模型中的目标,通过各个Agent的交互协作,模拟了RBC切换过程。其中各个Agent随机的运行时序,满足列控系统的并发性;对连续速度位置以及离散逻辑和交互的模拟,满足列控系统的混成性;对各个Agent协作交互的模拟,满足列控系统的交互性。
本文依据Multi-Agent理论,将列控系统技术规范与Prometheus建模方法相结合,提出了基于Multi-Agent的高铁列控系统复杂运营场景建模与仿真方法。并将该方法应用到CTCS-3级列控系统的RBC切换场景,仿真结果分析表明,该方法能够满足列控系统并发、混成、交互的复杂特性,填补了将Multi-Agent专用的建模方法及仿真平台应用于列控领域的空白。进一步研究可将一些故障情况注入系统,将监视到的数据用于系统安全分析。