【文章內(nèi)容簡介】 ety monitoring system of multi Agent整個系統(tǒng)的工作過程可以詳細的描述如下。Setp1 用戶通過人機界面Agent向主控Agent發(fā)布對煤礦井下環(huán)境信息進行監(jiān)控的請求信息，發(fā)布的信息具有一定的格式，便于檢索和瀏覽；Setp2 人機界面Agent了解用戶偏好，并詳細描述用戶需求，并將描述的需求信息轉(zhuǎn)發(fā)給主控Agent。Setp3主控Agent對用戶需求進行任務分析，確定系統(tǒng)其他Agent的任務并激活完成任務所涉及的Agent，并負責整個多Agent系統(tǒng)的資源分配。Setp4主控Agent分解任務后，通過查詢其控制的管理Agent是否有完成分解以后的子任務的能力。Setp5當主控Agent發(fā)現(xiàn)其控制的管理Agent不具備完成用戶的任務的能力，則反饋給用戶，無法完成任務。Setp6當主控Agent發(fā)現(xiàn)其控制的管理Agent能完成任務，則將任務分配給適合的管理Agent。Setp7啟動系統(tǒng)，Setp8管理Agent召集自己管理的監(jiān)測Agent，Setp9管理Agent將自己的任務進行分解，再根據(jù)監(jiān)測Agent與任務的匹配度，將分解后的子任務分配給適合的監(jiān)測Agent來完成，監(jiān)測Agent通過互動機制與其管理Agent進行協(xié)作來完成自己的任務，實現(xiàn)信息和資源的共享。Setp10當某個管理Agent（例如：管理Agent2）發(fā)生故障時，主控Agent首先根據(jù)檢測到的故障信息做出相應的診斷決策，然后將管理Agent的控制權(quán)限轉(zhuǎn)交給其它管理Agent或者進行任務的重新分配，從而使整個系統(tǒng)仍能正常執(zhí)行。這樣就實現(xiàn)了依靠各Agent之間的協(xié)作來提高整個系統(tǒng)的可靠性，而不是通過單個Agent的可靠性的冗余。Setp11監(jiān)測Agent完成來自管理Agent的分配任務后，將自己采集到的煤礦井下信息（例如瓦斯信息）反饋給自己控制的管理Agent，Setp12管理Agent將來自自己控制的監(jiān)測Agent的信息進行融合處理，將處理后的干凈、準確、簡化的信息通過工業(yè)以太網(wǎng)發(fā)送給主控Agent，同時查詢知識庫的知識，當發(fā)現(xiàn)自己管轄區(qū)域煤礦環(huán)境危險時（例如：瓦斯超限）時，立即報警，并將危險信息反饋給主控Agent，由主控通知相關(guān)工作人員處理。Setp13主控Agent將來自自己控制的管理Agent的信息進行融合處理，處理后反饋給人機交互Agent，同時根據(jù)知識庫的知識進行判斷，當發(fā)現(xiàn)煤礦環(huán)境危險時，立即報警，并通知相關(guān)工作人員處理。Setp14人機交互Agent將監(jiān)控到的煤礦井下復雜的環(huán)境信息反饋個用戶或者相關(guān)管理人員。 Agent間通信與協(xié)作在多Agent系統(tǒng)中，因為各Agent之間由于其結(jié)構(gòu)和行為的相關(guān)性，他們之間的通信及協(xié)作存在相互推動作用，也存在相互的影響，必須對這些通信及協(xié)作進行協(xié)調(diào)管理才能保證系統(tǒng)運行正常[32]。Agent間的協(xié)作通過通信實現(xiàn)，所以Agent的成功協(xié)作，需要在他們之間建立通信機制、通信語言和信息表示形式。如圖9所示就是Agent之間的通信結(jié)構(gòu)圖。圖9 Agent之間交互與協(xié)作模型Fig9 interaction and cooperation model between Agents由于煤礦井下環(huán)境信息復雜，單個Agent的智能性有限，受煤礦井下環(huán)境條件的約束無法完成煤礦井下環(huán)境信息的監(jiān)控，因此需要考慮多個Agent間的協(xié)調(diào)與合作。在煤礦監(jiān)控環(huán)境中，由于每個Agent的屬性是不一樣的，因此要選擇最佳的Agent來完成監(jiān)測任務，例如考慮Agent的資源利用率高的因素，這就是Agent的協(xié)調(diào)問題。在復雜的監(jiān)測問題及監(jiān)測系統(tǒng)中，必須基于多Agent的理論和技術(shù)，必須對復雜問題分解并運用多種方法進行監(jiān)測，這就是多Agent如何使用的問題。為了實現(xiàn)煤礦安全監(jiān)控任務，需要所有Agent的團結(jié)協(xié)作，因此要求Agent之間對彼此的功能、效率充分了解。在系統(tǒng)設計時，必須收集、歸納所有Agent的資料集中于數(shù)據(jù)庫內(nèi)，實際情況變化時Agent能夠?qū)ι婕白陨淼臄?shù)據(jù)進行修改，并重新尋找合作對象解決問題。Agent的行為通過協(xié)作交互算法表現(xiàn)出來，其中既包括單個Agent行為又包括由多個Agent合作的行為。它采用傳遞函數(shù)，實現(xiàn)各Agent間的信息交換，多Agent系統(tǒng)中問題求解過程中協(xié)作交互算法如下所示。設A為所有Agent的集合，A = {a1，a2，…，an}，則Ai，Aj表示A的不同的子集，Ai，Aj∈A。具體的交互算法如下流程圖所示。圖10交互算法流程圖Fig10 flow chart of interactive algorithm本文設計的多Agent的煤礦安全監(jiān)控系統(tǒng)中各Agent之間使用FIPA規(guī)范的通訊語言進行信息的交互，Agent間的通信機制層次模型如下圖11所示。圖11 遵循FIPA規(guī)范的Agent間的通信模型Fig11 the munication model between Agents following the FIPA specification 該模型自底向上：共分7層：網(wǎng)絡基礎設施層、傳輸層、報文傳輸協(xié)議層、消息封裝層、Agent通信語言層、內(nèi)容語言層、會話層。其中，網(wǎng)絡基礎設施層與傳輸層屬于網(wǎng)絡基礎知識范疇，本書不作贅述。下面對其他層次做以介紹。保報文傳輸協(xié)議層（Message Transport Protocol）報文傳輸協(xié)議層對Agent間的消息傳輸做出了下列規(guī)定：(1)每個Agent的名字都是唯一的、固定的；(2)每個Agent都對應一個或者多個傳輸描述（transport description），用來描述與傳輸相關(guān)的消息，如傳輸?shù)姆N類、傳輸?shù)刂返取?3)每一個傳輸描述都與一種傳輸形式相關(guān)，如IIOP、SMTP等。消息封裝層（Message Envelope）消息封裝層負責在消息傳送時將消息封裝成消息的有效負載payload，并加入到消息的傳輸隊列中。消息編碼使用適合傳輸?shù)木幋a表示機制進行編碼。消息的封裝過程如圖14過程。Agent通信語言層（Agent Communication Language）Agent通信語言層用以表達他關(guān)于通信內(nèi)容的觀點及態(tài)度、并將其傳輸給會話方的媒介或工具。內(nèi)容層（Content Language）內(nèi)容層指明消息內(nèi)容用什么語言來表達，在FIPA規(guī)范中，常見的內(nèi)容語言有SL，CCL，KIF，RDF等。會話層（Conversation）會話層是Agent用以管理整個會話過程的結(jié)果、規(guī)則和有關(guān)的會話策略。會話由一個或者多個消息組成，遵循Agent交互協(xié)議AIP。Agent之間通信基于言語行為理論，其基本原理是：說話人所說的話語不僅僅陳述一個事實，而且是說話人作出的帶有某種意圖的動作。消息即表示一種言語行為，用Agent通信語言ACLA編碼?？梢詫⑾⑿问綖閕 ，act(j，c)其中：i是言語行為的發(fā)起，即消息；act表示行為的名稱，向聽眾傳達說話人的意圖；j是消息的目標受眾；c是消息的語義內(nèi)容。交際行為也稱為原語，是消息的核心，常用的原語有：query、inform、request、agree、refuse等，見表3的說明。 表3消息原語Tab3 message primitives消息示例原語類型Is the door open?QueryOpen the door(for me)RequestOK!I’ll open the doorAgreethe door is openInformI am unable to open the doorFailureI will not open the doorRefuseSay when the door bees openSubscribeAnyone wants to open the doorcfp(call for proposal)I can open the door for you..at a priceProposeDoor? What’s that?Don’t understand…notunderstood消息的構(gòu)成如圖12所示。圖12消息的構(gòu)成Fig12 the structure of the message消息結(jié)構(gòu)中的主要參數(shù)如表4所列。表4 ACL 消息中的主要參數(shù)Tab4 the main parameters of ACLmessages參數(shù)參數(shù)的含義Performative指明ACL消息的通信動作類型，它是ACL唯一要求的必備參數(shù)。Sender表明消息的發(fā)信者。如以匿名發(fā)送，則可以忽略。Receiver表明消息的預期接受者?？梢圆晃ㄒ?，如隱含在內(nèi)容中，則可以忽略。Replyto表明這次會話過程中接下來到達的消息將送向哪個Agent。Content)制定消息的內(nèi)容，它的含義將被消息接受者所解釋。Language制定內(nèi)容是以什么語言表達的，如果接收者已經(jīng)知道，則可以忽略。Encoding指定內(nèi)容的編碼方式，如忽略，則在封裝 ACL 消息的信封中指出。Ontology消息本體，雙方都能夠理解的消息內(nèi)容的概念說明和語言描述Protocol指定 ACL 消息中使用的互操作協(xié)議。此參數(shù)非空的 ACL 消息被認為是屬于同一個會話過程，且必須遵循以下規(guī)則： 1協(xié)議會話的發(fā)起者必須指定一個非空的 Conversationid 參數(shù)；2在使用相同協(xié)議的會話中，接下來的消息都必須包含相同值的Conversationid 參數(shù)。3在使用相同協(xié)議的會話中，必須制定 replyby 參數(shù)來指定下一條消息出現(xiàn)的超時值。Conversationid指定消息所屬的會話過程。它必須是全局唯一的。在構(gòu)建ACL消息的基礎上，實現(xiàn)Agent之間通信。如果兩個Agent之間其中一個提供的服務是請求互操作協(xié)議(FIPA)，那么另一個Agent是此次互操作對話的發(fā)起者，它們首次的通信被看作請求互操作協(xié)議的第一個請求動作，在ACL庫規(guī)范中將這一動作描述為request行為，所以ACL的performative參數(shù)應為 request。詳細的ACL消息如表4所示。Agent 消息傳輸?shù)膮⒖寄Ｐ腿鐖D13。圖13消息傳輸參考模型Fig13 the message transmitted reference modelAgent 將自己要發(fā)送的 ACL 數(shù)據(jù)包經(jīng)過編碼形成有效載荷(Payload)，再通過 MTS （Message Transport Service）封裝信封(Envelope)發(fā)送到目的Agent。Agent是一個抽象的實體，具有反應性、自主性、自適應性和社會性的功能特征，它可以作用于自身和周圍環(huán)境，并能對周圍環(huán)境做出反應。與此同時Agent還具有知識和目標，可以和其他Agent進行交互和通信，具有解決問題的能力，在理論的基礎上，綜合現(xiàn)有的煤礦安全監(jiān)控系統(tǒng)的物理結(jié)構(gòu)，構(gòu)建了多Agent的煤礦安全監(jiān)控系統(tǒng)模型，并詳細闡述了多Agent的煤礦安全監(jiān)控系統(tǒng)的工作流程。733基于多Agent的煤礦安全監(jiān)控仿真系統(tǒng)3 基于多Agent的煤礦安全監(jiān)控仿真系統(tǒng)實現(xiàn)本章根據(jù)前章構(gòu)建的基于Agent的煤礦安全監(jiān)控系統(tǒng)模型的總體框架，進行平臺系統(tǒng)實現(xiàn)，實現(xiàn)多Agent系統(tǒng)的搭建。 概述JADE是一款遵循FIPA準則，采用java語言進行編寫的開發(fā)平臺，JADE平臺擁有完善的圖形界面，通過界面可以啟動、刪除、掛起Agent，還可以通過圖形界面和其他Agent進行信息的交互[4142]。每個JADE平臺都有一個主容器（MainContainer），每個主容器都有三種特殊的Agent，分別為：圖形控制臺(RMA)、Agent的管理系統(tǒng)（AMS）、目錄服務(DF)，三者在系統(tǒng)中都有獨特的用途。RMA為管理和控制圖形的界面，AMS為智能體提供命名服務，df為其它智能體提供服務，通過JADE平臺，可以對我們設計系統(tǒng)中的其他功能Agent注冊，如下圖1圖15所示。圖14主容器Fig14MainContainer圖15 JADE圖形界面的行為Fig15 the behavior of JADE GUI遵守FIPA標準的Agent平臺模型如下圖16所示。圖16 基于FIPA標準的Agent平臺參考結(jié)構(gòu)Fig16 the Agent platform reference architecture based on FIPA standard上圖16為基于FIPA標準的Agent平臺參考結(jié)構(gòu)，展示的依次為Agent的管理系統(tǒng)AMS（Agent Management System），其不但可以訪問JADE上的Agent，并可以使用它，當然由于處于管理地位，主要任務還是對Agent監(jiān)督和控制，對于每一個JADE來說這個管理系統(tǒng)是唯一的。任何一個Agent想要執(zhí)行相應操作，都需要獲得一個特有的AID，這些AID通過在AMS上注冊得到。圖16中的目錄服務器（DF，Directory Facilitator)是一個在平臺中提供默認黃頁服務的Agent，即為其它的智能體提供幫助的智能體。智能體可以從DF上執(zhí)行注冊、注銷、修改和搜索的行為。圖16中的消息傳輸系統(tǒng)（MTS，Message Transport System)也稱為Agent通信信道，是一個用于控制平臺中全部消息交換的軟件組件。對于Agent間的通信具有非常重要的作用，Agent間交互的信息就是通過MTS進行傳送的。 代理類的繼承和實現(xiàn)在MAS的建模過程中，首先需要完成的兩個步驟就是Agent的劃分、定義和Agent的屬性設定，這些步驟都需要通過繼承JADE的代理類來完成。 Agent的類，并且將HelloWorld Agent類的nickname定義為HelloWorld，那么以下將是我們應該看到的代理建立過程(，通過參數(shù)HelloWorld： Hel