王 碩，張亞東，郭 進，和貴恒

(西南交通大學信息科學與技術學院，成都 611756)

列車運行控制系統(tǒng)(簡稱：列控系統(tǒng))是高速鐵路的核心技術裝備，在保障行車安全、提高運輸效率方面具有重大作用[1]?，F(xiàn)代系統(tǒng)安全理論表明，隨著系統(tǒng)復雜度與耦合度的不斷提高，系統(tǒng)事故的發(fā)生往往不是若干危險致因事件簡單線性疊加作用的結果，而是由一系列危險致因事件相互作用、相互耦合而導致的。因此，需要對列控系統(tǒng)不同運營場景，特別是復雜運營場景，充分考慮列控系統(tǒng)的各種特性，對其進行建模與仿真，為列控系統(tǒng)復雜運營場景的系統(tǒng)安全分析奠定基礎。

目前有很多建模仿真方法應用于列控系統(tǒng)，其中廣泛應用的包括UML、Petri網、Scade等。文獻[2]利用UML2.0支持的底層語言擴展機制，構建面向列控系統(tǒng)混成特性的建模方法和原型工具。文獻[3-4]對UML面向混成性進行擴展，建立運營場景的UML模型，并將其轉換為PHAVer模型進行驗證。上述方法能夠滿足列控系統(tǒng)混成性的需求，但沒有體現(xiàn)列控系統(tǒng)的交互、并發(fā)特性。Petri網是具有嚴格語法語義的形式化方法，具備強大的數(shù)學理論支持，對系統(tǒng)的并發(fā)性也有很強的動態(tài)分析能力[5]。如文獻[6]利用有色Petri網對車載設備RBC切換的兩種方式分別建模，模擬在GSM-R網絡中消息的傳輸過程和重發(fā)機制[6]。文獻[7]采用著色Petri網對RBC與列車之間的無線通信進行研究。文獻[8]采用著色Petri網建立了列控中心軟件系統(tǒng)層次化模型，并利用狀態(tài)空間分析方法予以驗證。然而，UML與Petri網方法多以狀態(tài)變遷為重點，對于復雜的列控系統(tǒng)，任何一個場景的狀態(tài)都呈現(xiàn)“爆炸”的態(tài)勢，無法準確描述。Scade模型可以轉化為具有嚴格形式化語義的Lustre語言，能夠分析分布式系統(tǒng)的并發(fā)行為。如文獻[9]利用Scade數(shù)據流，建立系統(tǒng)功能性體系結構模型和功能故障模型，并將兩種模型集成起來進行分析，得到系統(tǒng)的安全關鍵功能和系統(tǒng)危險源。文獻[10]利用Scade對CBI系統(tǒng)進行建模和分析。但文獻[9-10]沒有提及系統(tǒng)混成性和交互性方面的論述。

Multi-Agent的思想來源于對生物界中群體運動現(xiàn)象的研究，通過功能獨立的Agent之間的交互協(xié)作，為復雜系統(tǒng)的建模與仿真實現(xiàn)提供了一條嶄新的途徑[11]。例如，文獻[12-13]提出了一種用于危害分析的Multi-Agent建模與仿真方法，并應用在軍事對抗復雜系統(tǒng)中，達到了很好的效果[12-13]。近年來，Multi-Agent被引入到列車控制領域，文獻[14]建立了基于Multi-Agent的CBTC系統(tǒng)仿真框架，對實體模型和功能模型進行了具體設計并實現(xiàn)仿真。文獻[15]利用Multi-Agent理論，建立了一種移動閉塞條件下的多車追蹤運行模型，并仿真研究了列車追蹤運行的速度和密度問題。文獻[16]應用Multi-Agent技術，建立了應急聯(lián)鎖系統(tǒng)的框架，并用C語言編程實現(xiàn)了分布式聯(lián)鎖軟件。然而目前Multi-Agent在列車控制領域的應用多與文獻[14-16]相似，只是引用了Multi-Agent理論的概念進行模型設計，并沒有采用面向Multi-Agent建模的工具和方法，并且在仿真過程中也依然采用傳統(tǒng)的面向對象或面向過程的編程方法，沒有充分發(fā)揮Multi-Agent在描述模擬列控系統(tǒng)特性方面的優(yōu)勢。

因此，本文研究適用于列控系統(tǒng)特性的Multi-Agent建模仿真方法，并提出了基于Multi-Agent的高鐵列控系統(tǒng)復雜運營場景建模與仿真方法。該方法采用Multi-Agent理論，將列控系統(tǒng)技術規(guī)范與Prometheus建模方法相結合，并利用Multi-Agent仿真工具實現(xiàn)仿真。

1 Multi-Agent建模仿真理論基礎

1.1 Agent定義

Agent目前尚無統(tǒng)一的概念，本文引用如下定義。Agent是位于環(huán)境中的，具有自治性、反應性、主動性、靈活性、健壯性、社會性的程序軟件[17]。其組成包括感知(Percepts)、動作(Actions)、目標(Goals)、計劃(Plans)、事件(Events)、信念(Beliefs)等。其中，感知是通過一些傳感器從環(huán)境獲取信息；動作是Agent做出一些影響環(huán)境的行為；目標是Agent主動去實現(xiàn)達成的任務；事件是由感知形成的，需要Agent以某種方式做出反應；信念是Agent關于環(huán)境的認識；計劃是實現(xiàn)目標的方法；它們之間的相互作用關系如圖1所示[17]。

圖1 Agent元素間相互作用關系示意

1.2 Prometheus方法

Prometheus方法是比較成熟的面向Agent的軟件開發(fā)方法，該方法定義了一個詳細的過程用來說明、設計、實施、測試面向Agent的軟件系統(tǒng)。PDT(Prometheus Design Tool)是支持Prometheus方法的自動化模型設計工具，在應用過程中會產生一系列圖形和文本的描述，這些圖形和描述均與Agent的元素相對應并作為仿真設計的依據。

Prometheus方法具體包括3個階段。第一階段是系統(tǒng)規(guī)范階段，分析確定系統(tǒng)的目標和基本功能，同時確定系統(tǒng)的感知輸入及動作輸出，該階段PDT會產生目標概況圖模型。第二階段是結構設計階段，確定系統(tǒng)中需要幾種Agent類型以及它們之間的交互，該階段PDT會產生系統(tǒng)概況圖模型以及交互協(xié)議圖。第三階段是詳細設計階段，關注每種Agent內部的邏輯以及在整個系統(tǒng)中如何完成自身的目標，該階段PDT會產生Agent概況圖模型。3個階段中PDT產生的模型涉及了感知(Percept)、動作(Action)、協(xié)議(Protocol)、Agent、目標(Goal)、能力(Capability)、數(shù)據(Data)、消息(Message)、計劃(Plan)等元素，表示它們的圖元如圖2所示。

圖2 Agent元素圖元示意

1.3 MASON仿真平臺

MASON是Multi-Agent仿真平臺，采用結構化程序設計且可充分利用PDT建立的Multi-Agent模型。MASON擺脫了大多數(shù)Agent仿真平臺都側重于社會科學領域的缺陷，是通用的Multi-Agent仿真平臺。其理念之一是最大化執(zhí)行速度，能夠保證列控系統(tǒng)這類復雜系統(tǒng)仿真模擬的重現(xiàn)。

此外，MASON廣泛應用于處理2維空間中連續(xù)的群體運動行為，群體運動中涉及了Multi-Agent間的交互、并發(fā)、混成等性質，因而能夠滿足列控系統(tǒng)特性的需求。

2 列控系統(tǒng)Multi-Agent建模仿真方法

列控系統(tǒng)Multi-Agent建模仿真方法框架如圖3所示，分為6步。

圖3 列控系統(tǒng)Multi-Agent建模仿真方法框架

(1)依據技術規(guī)范，選定列控系統(tǒng)的運營場景，確定系統(tǒng)邊界，做出合理假設，提取設備主體、功能、交互等相關描述。

(2)確定系統(tǒng)和子系統(tǒng)所需完成的目標以及從環(huán)境感知的信息以及作用于環(huán)境的動作。

(3)根據系統(tǒng)包含的設備主體，確定Agent類型以及它們之間的交互行為。

(4)對每種Agent類型完成相應目標的計劃邏輯進行描述，并對PDT產生的模型進行校驗。

(5)根據Multi-Agent模型，利用MASON編程實現(xiàn)仿真。

(6)利用MASON中的監(jiān)視器，監(jiān)視各個Agent運行中產生的數(shù)據，并以此分析目標實現(xiàn)情況以及對列控系統(tǒng)的適用情況。

2.1 列控系統(tǒng)的規(guī)范提取

對完整的列控系統(tǒng)進行建模仿真，無疑是太過龐大和復雜，難以把握建模仿真的重點。選擇典型的運營場景進行研究，既能夠較容易地從規(guī)范中提取信息，又能夠把握建模仿真的重點。同理，一個運營場景要實現(xiàn)其目標需要獲取大量的信息，有些信息的產生過程與場景并非緊密相關，因而劃定系統(tǒng)邊界，令一些信息為外部環(huán)境信息(不關注該信息如何產生，只關注該信息對系統(tǒng)目標的作用)，進一步簡化建模仿真的規(guī)模。

經過簡化處理后，從規(guī)范中提取指定場景涉及的設備主體、功能以及交互的描述，為建模奠定基礎。其中設備主體的提取主要確定場景中涉及哪些設備，以文本的方式記錄并進行命名，為后續(xù)建模抽象Agent類型奠定基礎。其次，根據各個設備主體的技術規(guī)范提取涉及的功能名稱、功能描述及功能執(zhí)行條件，以功能列表的形式進行記錄，為確定Agent目標任務提供依據。最后，各個設備主體之間的關系及交互信息以序列圖的形式進行提取，為確定Agent間的交互及系統(tǒng)中各個Agent的關系提供依據。

2.2 列控系統(tǒng)場景的Multi-Agent建模

基于規(guī)范中提取的內容，利用Prometheus方法及其支持工具PDT進行Multi-Agent建模。在建模過程中，充分利用從規(guī)范中提取的內容，能夠簡化Prometheus方法中的一些中間步驟，使得構建的模型既來源于規(guī)范，又符合Prometheus方法。

首先利用提取的功能描述構建Agent的目標概況圖模型。將場景中的系統(tǒng)級功能構建為目標概況圖的頂級目標，然后將為了實現(xiàn)系統(tǒng)級功能而必須實現(xiàn)的各個子功能構建為頂目標下的子目標，以此逐層深入直至場景中所有交互的內容都有指定的子目標相對應。

其次構建系統(tǒng)概況圖模型，確定Agent類型及Agent類型之間的交互。在確定系統(tǒng)Agent類型過程中，直接根據提取的設備主體進行劃分，例如將列車、車載設備、RBC等確定為不同的Agent類型。然后，需要詳細描述Agent類型之間以及與環(huán)境的交互，并以AUML(Agent UML)符號進行表示。

最后詳細設計Agent內部實現(xiàn)其目標的邏輯，構建每個Agent類型的Agent概況圖模型。Agent概況圖模型表達了Agent內部為實現(xiàn)其目標的輸入輸出邏輯關系，其中計劃是Agent類型中輸入輸出的邏輯表達，而能力是一組計劃的集合。消息和數(shù)據則為Agent的輸入輸出或內部邏輯的中間產物。

至此產生了一些圖形化的Multi-Agent模型，圖形化模型中的每個元素還全部附有相應的文本描述。其中文本描述主要包括元素的關系和屬性兩種，關系描述是在建模過程中自動生成的；屬性描述由人工完成，是對各元素作用、邏輯、參數(shù)、公式等的表達。

模型的校驗過程分為兩部分，以保證模型的準確性。首先，人工檢驗規(guī)范提取過程中有無遺漏的、錯誤的功能或交互信息以及Multi-Agent模型是否全部準確描述了這些功能和交互信息。其次，PDT能夠自動校驗元素的命名、交互協(xié)議的完整以及邏輯表達與交互內容的對應。

2.3 仿真實現(xiàn)與分析

依據每種Agent類型所需要完成的目標，以Agent概況圖設計Agent類型中的變量及函數(shù)，根據“計劃”描述模型實現(xiàn)具體函數(shù)。之后，根據交互協(xié)議模型，通過MASON提供的Networks實現(xiàn)信息交互設計。再根據系統(tǒng)概況圖模型將環(huán)境與Agent關聯(lián)起來。最后，利用MASON提供的監(jiān)視器動態(tài)監(jiān)視系統(tǒng)中Agent內部的運行數(shù)據，分析列控系統(tǒng)仿真中各個Agent的運行情況。

此外，利用MASON的schedule方式打亂時間步次序，模擬系統(tǒng)中各子系統(tǒng)的并發(fā)行為；利用MASON的高質量隨機數(shù)生成器模擬列控系統(tǒng)中測速定位誤差、通信延時誤差等不確定因素。

3 RBC切換場景Multi-Agent建模仿真實例

RBC切換是CTCS-3級列控系統(tǒng)14個主要場景之一，描述了在不同RBC邊界處，實現(xiàn)列車在兩個RBC間行車許可控制的安全切換過程[18]。RBC切換包括兩部GSM-R無線電臺都正常和只有一部GSM-R無線電臺正常的場景，本例研究兩部GSM-R無線電臺都正常的場景。

3.1 RBC切換規(guī)范提取

本例系統(tǒng)范圍界定為包括Train(列車)、OBE(車載設備)、RBCH(移交RBC)、RBCA(接收RBC)，設定列車的速度位置作用于環(huán)境，聯(lián)鎖信號授權、應答器信息、測速定位數(shù)據從環(huán)境獲取。RBC切換場景部分功能列表舉例如表1所示。

表1 RBC切換場景部分功能

文獻[18-20]中描述了兩部電臺都正常的RBC切換流程，并有車地無線通信的消息內容，將其提取為序列圖，如圖4所示。

3.2 RBC切換的Multi-Agent建模

依據提取的功能列表建立目標概況模型如圖5所示，該圖主要以RBC切換和Train監(jiān)控為兩個頂目標，逐層構建各個子系統(tǒng)需要完成的目標。

根據目標概況圖模型及系統(tǒng)范圍界定建立RBC切換場景的系統(tǒng)概況圖模型，如圖6所示。該模型表達了RBC切換場景Multi-Agent模型所包含的Agent類型、Agent類型之間的交互關系、與環(huán)境之間的作用關系等，是模型中的核心的部分。

兩個Agent類型之間交互內容的具體邏輯通過AUML描述，例如RBC切換場景中OBE-Train交互協(xié)議的AUML圖，如圖7所示，OBE從環(huán)境獲得測速測距信息，經運算判斷列車超速情況并下達制動命令；而列車的實際速度位置更新則作用于外部環(huán)境。

圖4 RBC切換場景序列

圖5 RBC切換場景目標概況模型

Agent內部邏輯關系的構建以Trainagent為例，其主要邏輯為根據收到的常用制動命令和緊急制動命令觸發(fā)相應執(zhí)行命令計劃，從而使速度更新和位置更新作用于環(huán)境。Trainagent的Agent概況圖模型如圖8所示。

圖6 RBC切換場景系統(tǒng)概況模型

圖7 RBC切換場景OBE-Train交互協(xié)議AUML圖

圖8 Trainagent概況圖模型

3.3 RBC切換場景仿真實現(xiàn)與分析

根據RBC切換Multi-Agent模型，利用MASON仿真平臺編程實現(xiàn)仿真。其中，利用模型監(jiān)視器對Trainagent、OBEagent、RBCHagent、RBCAagent內部交互情況以及列車的實際速度位置、車載獲取速度位置的監(jiān)視情況如圖9所示(長度單位：m；時間單位：s)。

圖9 RBC切換場景動態(tài)運行數(shù)據監(jiān)視

圖10 Trainagent與OBEagent的位置走勢

圖9反映了Trainagent與OBEagent的速度位置隨時間的變化以及OBEagent讀取應答器校正位置并向RBCH報告位置的交互情況。但由于測速誤差的存在Trainagent與OBEagent的速度位置數(shù)值并未保持一致，圖10監(jiān)視了二者位置隨時間變化的走勢，二者位置誤差隨時間積累越來越大，但在1 000 m附近由于應答器的存在誤差幾乎消失，模擬了列控系統(tǒng)中的實際運行情形。

Agent的執(zhí)行順序是指在系統(tǒng)一個時間周期中，各個Agent的執(zhí)行順序，從圖11中觀察到，各個Agent并不是以固定的時序執(zhí)行，而是以隨機的時序運行。通過此種方式模擬場景各個Agent并發(fā)執(zhí)行的過程，以滿足列控系統(tǒng)的并發(fā)性。

圖11 各個Agent執(zhí)行順序

從整個動態(tài)仿真數(shù)據可以看出，RBC切換場景Multi-Agent仿真實現(xiàn)了模型中的目標，通過各個Agent的交互協(xié)作，模擬了RBC切換過程。其中各個Agent隨機的運行時序，滿足列控系統(tǒng)的并發(fā)性；對連續(xù)速度位置以及離散邏輯和交互的模擬，滿足列控系統(tǒng)的混成性；對各個Agent協(xié)作交互的模擬，滿足列控系統(tǒng)的交互性。

4 結語

本文依據Multi-Agent理論，將列控系統(tǒng)技術規(guī)范與Prometheus建模方法相結合，提出了基于Multi-Agent的高鐵列控系統(tǒng)復雜運營場景建模與仿真方法。并將該方法應用到CTCS-3級列控系統(tǒng)的RBC切換場景，仿真結果分析表明，該方法能夠滿足列控系統(tǒng)并發(fā)、混成、交互的復雜特性，填補了將Multi-Agent專用的建模方法及仿真平臺應用于列控領域的空白。進一步研究可將一些故障情況注入系統(tǒng)，將監(jiān)視到的數(shù)據用于系統(tǒng)安全分析。