劉仕兵, 張晨暉
(華東交通大學 電氣與自動化工程學院,江西 南昌 330013)
我國城市地下鐵道的發(fā)展起步相比于發(fā)達國家晚了100 a,“互聯(lián)網(wǎng)+城市軌道交通”的概念還處于萌芽階段。盡管少數(shù)一線城市在這方面走在了前列,信息化建設(shè)覆蓋到了多個專業(yè),部分專業(yè)的管理通過信息化手段取得了顯著的成果,但是多專業(yè)之間的業(yè)務(wù)關(guān)聯(lián)與閉環(huán)并沒有實現(xiàn)。在數(shù)據(jù)分析領(lǐng)域也只是停留在多專業(yè)數(shù)據(jù)匯總的階段,并沒有實現(xiàn)通過自動采集到的數(shù)據(jù)自動校正業(yè)務(wù)管理過程,即數(shù)據(jù)驅(qū)動業(yè)務(wù)閉環(huán),實現(xiàn)智能化管理。而針對城市軌道交通運維管理信息系統(tǒng)這一重要交叉學科的調(diào)查研究本就不多,實際建設(shè)更是少有涉及??傮w來講,伴隨各城市線路規(guī)模的激增,各專業(yè)信息化手段的增加,智能化已然成為信息系統(tǒng)發(fā)展的必然趨勢。現(xiàn)以中鐵電氣化局集團第一工程有限公司智能運維平臺項目為研究對象進行探究。
目前,城市軌道交通智能運維管理信息平臺(以下簡稱智能運維平臺)在國內(nèi)城市中應用較為鮮見,需求和功能也不成熟,難以適應現(xiàn)代化管理的需要。上海地鐵根據(jù)實際業(yè)務(wù)需求,在“十五”期間初步搭建出了地鐵管理信息系統(tǒng),因為數(shù)據(jù)采集困難、業(yè)務(wù)邏輯未形成閉環(huán),該系統(tǒng)發(fā)揮的作用較小。在“十一五”期間,建立了新型的檢修、維修制度,并基于此對原有系統(tǒng)進行更新?lián)Q代,對于各類設(shè)備的運營維護有了較大的幫助。在“十二五”期間頒布了一系列的信息化政策應用于制訂數(shù)據(jù)架構(gòu)的技術(shù)框架標準與制度,對設(shè)備采購、備件、系統(tǒng)安全等進行了重點攻克[1-2]。
香港地鐵(以下簡稱港鐵)的信息化建設(shè)進度在全國名列前茅,港鐵根據(jù)多年的運營管理經(jīng)驗不斷升級管理信息系統(tǒng)。針對突發(fā)危機狀況,港鐵建立了快速反應應對系統(tǒng);針對人事管理、財務(wù)管理等建立了公司資源計劃管理系統(tǒng);針對故障維修、施工計劃管理、人員作業(yè)等建立了工程維護管理信息系統(tǒng)等。港鐵能成為國內(nèi)唯一一家不依靠政府資助還能盈利的地鐵公司,管理信息系統(tǒng)的建設(shè)當居首功[3]。
智能運維平臺涉及到各種不同的軟件或者設(shè)備在平臺中集成,不同的軟件/設(shè)備架構(gòu)不同、功能不同,且集成多個軟件/設(shè)備意味著數(shù)據(jù)量十分龐大,智能運維平臺攜帶的多樣性、異構(gòu)性是平臺信息集成路上的絆腳石[4]。一個優(yōu)秀的智能運維平臺所必備的特質(zhì)之一是在線可擴展性[5],這一特性確保智能運維平臺可以隨時根據(jù)業(yè)務(wù)需求集成所需要的各類子系統(tǒng),而且當任意數(shù)量的外來子系統(tǒng)加入處于運轉(zhuǎn)狀態(tài)的智能運維平臺上時,或者當子系統(tǒng)有更新的需求或需要修訂系統(tǒng)功能時,平臺依然可以保持正常運轉(zhuǎn)并及時獲取新加入的子系統(tǒng)發(fā)布的全部信息內(nèi)容。
為解決搭建智能運維平臺所遇到的困難,從軟件系統(tǒng)架構(gòu)入手,輔以數(shù)據(jù)交互機制作為支撐技術(shù),再加上合理的業(yè)務(wù)架構(gòu)的閉環(huán)設(shè)計,讓智能運維平臺擁有高效實時的數(shù)據(jù)交互機制,高度解耦、高度內(nèi)聚的軟件架構(gòu),智能的業(yè)務(wù)閉環(huán)卡控體系。(1)高內(nèi)聚低耦合的軟件架構(gòu)可以將架構(gòu)層次足夠抽象化,讓各子系統(tǒng)之間可以高速有效地進行數(shù)據(jù)交互,是實現(xiàn)可維護、可擴展的智能運維平臺的樞紐[6]。(2)高效實時的數(shù)據(jù)交互機制可以在線分析、挖掘外界環(huán)境、設(shè)備或業(yè)務(wù)流程產(chǎn)生的數(shù)據(jù),最大程度地排除無效數(shù)據(jù),降低無效的交互操作量,在提升通信效率的同時提高工作效率,降低對通信基礎(chǔ)設(shè)施的技術(shù)要求。(3)合理的業(yè)務(wù)邏輯流轉(zhuǎn)體系使得信息化管理過程無需人工分析,為智能運維平臺真正實現(xiàn)智能化奠定基礎(chǔ)。
在前文思路的基礎(chǔ)上,提出基于自律分散系統(tǒng)(autonomous decentralized system,ADS)理論的平臺構(gòu)建方案——以分層架構(gòu)為核心的智能運維平臺。該平臺構(gòu)建方案以自律分散系統(tǒng)理論作為基礎(chǔ)理論,以分層架構(gòu)作為設(shè)計思路,把數(shù)據(jù)驅(qū)動作為核心機制,三位一體,以此為基礎(chǔ)來實現(xiàn)智能運維平臺在線可擴展性。
智能運維平臺通過數(shù)據(jù)驅(qū)動機制[7]的4個關(guān)鍵步驟——“感知、分析、決策、執(zhí)行”來實現(xiàn)智能運維平臺數(shù)據(jù)自主流轉(zhuǎn)的閉環(huán)卡控體系,可以使數(shù)據(jù)從物質(zhì)世界的抽象狀態(tài)經(jīng)過處理后變?yōu)槿祟惪梢宰x懂的具象化信息,最后優(yōu)化為標準數(shù)據(jù)并儲存在系統(tǒng)中,形成標準知識庫。感知是指通過傳感器感知物理世界的運行狀態(tài),如環(huán)境監(jiān)測、線路監(jiān)測、接觸網(wǎng)狀態(tài)檢測等;分析是指利用各種軟件使抽象數(shù)據(jù)變?yōu)榫呦髷?shù)據(jù),再向標準數(shù)據(jù)轉(zhuǎn)化的過程;決策是指利用大數(shù)據(jù)處理技術(shù)實現(xiàn)不同系統(tǒng)之間的數(shù)據(jù)自主流轉(zhuǎn)與共享,并生成指導性數(shù)據(jù)作為決策依據(jù);執(zhí)行是指相關(guān)系統(tǒng)接收到指導性數(shù)據(jù)后利用硬件設(shè)備做出對決策的實時反饋。在數(shù)據(jù)驅(qū)動機制中感知的目標是數(shù)據(jù),分析的結(jié)果是數(shù)據(jù),決策的依據(jù)是數(shù)據(jù),執(zhí)行的輸出依然是數(shù)據(jù)。顯而易見,數(shù)據(jù)成為智能運維平臺的靈魂[8]。
20世紀80年代,傳統(tǒng)的計算機系統(tǒng)均為集中式系統(tǒng),其信息資源集中,管理方便,規(guī)范統(tǒng)一。但集中式系統(tǒng)是一個主機帶多個終端的模式,終端沒有處理數(shù)據(jù)的功能,這帶來2個問題,一是如果主機出現(xiàn)故障,整個系統(tǒng)將無法正常運轉(zhuǎn);二是由于系統(tǒng)功能的不斷擴展,系統(tǒng)在升級擴展以及維護的同時需要中斷整個系統(tǒng)的運行。自律分散系統(tǒng)很好地解決了這些問題[9]。
區(qū)別于傳統(tǒng)系統(tǒng),ADS提出了2個新的系統(tǒng)觀點——“異常就是正常”、“系統(tǒng)由子系統(tǒng)集成”。
(1)異常就是正常。如圖1(a)所示,對于傳統(tǒng)系統(tǒng)來說,“正?!贝碇到y(tǒng)C中的12個子系統(tǒng)全面完成建設(shè),且12個子系統(tǒng)功能完好,反之系統(tǒng)為“異?!睜顟B(tài)。一般來說,傳統(tǒng)的子系統(tǒng)之間都互相依賴,缺一不可,導致傳統(tǒng)系統(tǒng)“異?!睍r是不可以正常運轉(zhuǎn)的。而自律分散系統(tǒng)理論摒棄了傳統(tǒng)系統(tǒng)的劣勢,提出系統(tǒng)應該始終處于持續(xù)維護或升級的狀態(tài),也就不會出現(xiàn)“系統(tǒng)全面建設(shè)完善并功能完備才可運轉(zhuǎn)”、“系統(tǒng)升級或發(fā)生故障時系統(tǒng)無法正常運轉(zhuǎn)”的情況。如圖1(b)所示,B中有3個子系統(tǒng)處于故障或升級狀態(tài),但并不會對另外9個子系統(tǒng)造成影響,系統(tǒng)A仍能獨立完成工作。圖1(b)所示系統(tǒng)一直處在“異?!睜顟B(tài)的情況在ADS中才是常態(tài),即“異常就是正?!?。
圖1 自律分散系統(tǒng)概念圖
(2)系統(tǒng)由子系統(tǒng)集成。傳統(tǒng)系統(tǒng)認為“先有整體系統(tǒng)再有子系統(tǒng)”,也就是說子系統(tǒng)的運行完全依賴于整體系統(tǒng)這個平臺,是不可以獨立運行的。這一特性導致當整體系統(tǒng)的架構(gòu)、性能、服務(wù)對象等需求不清晰的時候,無法構(gòu)建系統(tǒng)。在這個大數(shù)據(jù)時代,系統(tǒng)規(guī)模越來越大,加上客戶需求的不斷變更,一旦需要添加新的子系統(tǒng),原有的系統(tǒng)架構(gòu)便無法滿足需求,需要重新設(shè)計架構(gòu)。顯然,傳統(tǒng)系統(tǒng)的絕對論系統(tǒng)觀已然不適應這個時代的發(fā)展,ADS應運而生,它認為“系統(tǒng)由子系統(tǒng)集成”,就是說不再用整體系統(tǒng)來限制內(nèi)部子系統(tǒng)的存在,而是把整體系統(tǒng)重新定義成多個子系統(tǒng)的集合。
ADS彌補了傳統(tǒng)的C/S架構(gòu)的劣勢,完全做到了在線擴展、在線維護以及在線容錯,即在不停止系統(tǒng)運轉(zhuǎn)的情況下,可以對子系統(tǒng)進行增刪改查、故障修復等操作。ADS逐漸應用在越來越多的專業(yè),其中包括電力系統(tǒng)[10]、航空監(jiān)管[11],近些年在交通調(diào)度[12]領(lǐng)域也得到了青睞。
最基本的ADS由2個部分組成,原子節(jié)點(Atom)和數(shù)據(jù)域(Data Field,DF)[13]。從物理概念上講,原子節(jié)點相當于電腦、智能化設(shè)備或其他硬件。數(shù)據(jù)域是ADS中用來傳播信息的邏輯空間,它對應的物理實體為網(wǎng)絡(luò)或存儲器等。結(jié)構(gòu)模型如圖2所示。
圖2 基于ADS的數(shù)據(jù)驅(qū)動系統(tǒng)結(jié)構(gòu)
2.2.1 數(shù)據(jù)域
數(shù)據(jù)域是一個能使各模塊共享數(shù)據(jù)的邏輯空間,原子節(jié)點之間的數(shù)據(jù)交互只能在數(shù)據(jù)域中通過廣播的形式來實現(xiàn),數(shù)據(jù)均在數(shù)據(jù)域中循環(huán)流動。從數(shù)據(jù)域中延伸了一部分進入原子節(jié)點中,這部分叫做原子數(shù)據(jù)域(Atom Data Field,ADF),原子節(jié)點訂閱的數(shù)據(jù)則進入到原子數(shù)據(jù)域內(nèi)循環(huán)流動。
2.2.2 原子節(jié)點
所有原子節(jié)點均向數(shù)據(jù)域中發(fā)布數(shù)據(jù),與此同時所有原子節(jié)點也從數(shù)據(jù)域中訂閱數(shù)據(jù)。原子節(jié)點之間是不會有直接聯(lián)系的,它們均為獨立的單元,只需要辨別數(shù)據(jù)域中的數(shù)據(jù)內(nèi)容是否為自己需要的,而不需要知道此數(shù)據(jù)的發(fā)布者是誰,因此實現(xiàn)了原子節(jié)點的局部性,即每個原子節(jié)點都是平等的。所有的原子節(jié)點中均含有自律控制處理器 (autonomous control processor,ACP),發(fā)布在數(shù)據(jù)域中的數(shù)據(jù)都涵蓋一個定義其自身屬性的內(nèi)容碼(Content Code,CC),原子節(jié)點正是利用ACP來識別該內(nèi)容碼繼而判斷是否需要訂閱該數(shù)據(jù)。以內(nèi)容碼識別為基礎(chǔ)的數(shù)據(jù)交互機制確保了原子節(jié)點能準確高效地發(fā)送、接收信息。
以本次研究對象中鐵電氣化局第一工程有限公司的智能運維平臺為例來說明。智能運維平臺是以各專業(yè)日常巡視、檢修任務(wù)、故障處理為信息基礎(chǔ),將其他管理模塊綜合一體化的全自動運行系統(tǒng)。實現(xiàn)各維保項目的人員管理、培訓考核、巡視檢修、故障處理等工作任務(wù)自動運行。通過智能運維平臺的實施對維保項目一體化業(yè)務(wù)進行全要素、全流程管理,建立多業(yè)務(wù)之間的關(guān)聯(lián)規(guī)則[14],實現(xiàn)業(yè)務(wù)生成數(shù)據(jù)、數(shù)據(jù)輔助業(yè)務(wù)的閉環(huán)卡控體系。智能運維平臺擬定為13大功能模塊,包括信息平臺模塊、維修中心模塊、標準中心模塊、系統(tǒng)管理模塊等,其建設(shè)目標以接觸網(wǎng)、變電、信號等專業(yè)的實際需求為中心,引入自律分散系統(tǒng)理念,并對軟件系統(tǒng)進行分層架構(gòu)[15-18]設(shè)計。
智能運維平臺由硬件系統(tǒng)和軟件系統(tǒng)組成。為滿足軟件架構(gòu)高內(nèi)聚、低耦合的需求,把軟件系統(tǒng)架構(gòu)設(shè)計為分層架構(gòu),該設(shè)計突破了傳統(tǒng)的3層架構(gòu),即用戶界面層、業(yè)務(wù)邏輯層、數(shù)據(jù)訪問層,該架構(gòu)將數(shù)據(jù)訪問層改為基礎(chǔ)設(shè)施層,并在此基礎(chǔ)上做了微調(diào),在用戶界面層和業(yè)務(wù)邏輯層中新加一層,即業(yè)務(wù)應用層。分層架構(gòu)如圖3所示,將系統(tǒng)架構(gòu)分為4層:基礎(chǔ)設(shè)施層(Infrastructure Layer)、業(yè)務(wù)邏輯層(Business Logic Layer)、業(yè)務(wù)應用層(Business Application Layer)、用戶界面層(User Interface Layer),并對每一層進行功能設(shè)計,用戶界面層面向用戶,業(yè)務(wù)應用層面向應用,業(yè)務(wù)邏輯層面向業(yè)務(wù),基礎(chǔ)設(shè)施層面向外部資源/設(shè)備。
圖3 分層架構(gòu)示意圖
從圖3中可以看出,基礎(chǔ)設(shè)施層是業(yè)務(wù)邏輯層、業(yè)務(wù)應用層、用戶界面層的基礎(chǔ),包括確保智能運維平臺運轉(zhuǎn)的軟件設(shè)備、硬件設(shè)備以及環(huán)境。硬件設(shè)備包含了服務(wù)器、芯片處理器、傳感器、存儲設(shè)備、充電設(shè)備等;軟件設(shè)備包含數(shù)據(jù)中心、云平臺、移動操作終端等;環(huán)境包含各類設(shè)備及工作人員所處的外界環(huán)境。該層負責數(shù)據(jù)訪問、數(shù)據(jù)整合,也即對數(shù)據(jù)的增刪改查操作,不負責檢測該數(shù)據(jù)是否正確,不需要知道數(shù)據(jù)的來源及用途,不牽扯到業(yè)務(wù)邏輯。
該層是整個系統(tǒng)的核心,該層封裝了所有的業(yè)務(wù)邏輯,將業(yè)務(wù)邏輯高度內(nèi)聚在業(yè)務(wù)邏輯層,實現(xiàn)業(yè)務(wù)邏輯層與其他層的松耦合,避免業(yè)務(wù)邏輯暴露在用戶界面層或業(yè)務(wù)應用層,提升平臺系統(tǒng)的在線可擴展性。該層包含了業(yè)務(wù)規(guī)則,負責處理系統(tǒng)業(yè)務(wù),并判斷接收的數(shù)據(jù)內(nèi)容是否正確、有效,而對于輸出的數(shù)據(jù)內(nèi)容及其在用戶界面的展示樣式均不負責。
在理解業(yè)務(wù)邏輯的基礎(chǔ)上,對模塊關(guān)聯(lián)關(guān)系進行深入分析,以維修業(yè)務(wù)為例,以維修中心管理為主線描繪的業(yè)務(wù)邏輯關(guān)系如圖4所示。
圖4 業(yè)務(wù)流轉(zhuǎn)邏輯示意圖
圖4中右側(cè)閉環(huán)是主線維修管理業(yè)務(wù)部分,其他安全管理、教育培訓、人力資源管理、物資及工器具管理模塊都是用來輔助主線業(yè)務(wù)的功能模塊。圓圈中含有D的是指數(shù)據(jù)經(jīng)過數(shù)據(jù)中心采集過濾,S代表已經(jīng)在標準中心建立關(guān)聯(lián)關(guān)系。
從圖4可以看出從4個方面來卡控維修業(yè)務(wù)。
(1)設(shè)備檢測獲得的數(shù)據(jù)加上人工判斷等得到的數(shù)據(jù)導入缺陷故障庫,以此形成標準庫,根據(jù)故障具體情況,系統(tǒng)會匹配近似預案生成作業(yè)指派來卡控開作業(yè)票。
(2)根據(jù)作業(yè)人員持有作業(yè)證書、安全等級的不同來指派不同的人員進行作業(yè)進而卡控開作業(yè)票。
(3)根據(jù)考勤與交接班管理來指派不同人員進行作業(yè)進而卡控開作業(yè)票。
(4)根據(jù)現(xiàn)有庫存的物資和工器具的領(lǐng)取、歸還記錄來卡控維修作業(yè)指派。根據(jù)設(shè)備履歷以及維修概況,系統(tǒng)會自動生成差異化維修年計劃并自動分解為月計劃、周計劃以及日計劃,各班組人員根據(jù)計劃開作業(yè)票,生成單據(jù),錄入臺賬,而臺賬又會自動更新設(shè)備履歷以及生成維修概況,進而更新維修年計劃,周而復始,整個維修業(yè)務(wù)形成了閉環(huán),實現(xiàn)了業(yè)務(wù)生成數(shù)據(jù)、數(shù)據(jù)輔助業(yè)務(wù)的閉環(huán)卡控體系。
智能運維平臺基于基礎(chǔ)數(shù)據(jù)與業(yè)務(wù)數(shù)據(jù)相互之間循環(huán)卡控的業(yè)務(wù)邏輯過程,實現(xiàn)了自動更新設(shè)備履歷、物資庫存及工時統(tǒng)計的功能,能夠?qū)收辖y(tǒng)計與日常生產(chǎn)計劃進行智能分析,自動生成設(shè)備差異化維修計劃,并自動分解計劃落實到個人?;跇藴驶瘮?shù)據(jù)結(jié)果分析,平臺可以針對設(shè)備故障自動匹配近似預案,同時對故障類型、專業(yè)、設(shè)備維護方案自動生成專家數(shù)據(jù)庫,為維修決策提供指導性依據(jù)。
圖5 應用場景——智能巡檢儀
業(yè)務(wù)應用層是很薄的一層,用來協(xié)調(diào)應用的活動,不包含業(yè)務(wù)邏輯,負責決定軟件系統(tǒng)能做什么,不負責如何去做。它不保留業(yè)務(wù)對象的狀態(tài),但保有應用任務(wù)的進度狀態(tài),例如事務(wù)審批、日志管理、安全訪問控制等應用。
以智能巡檢儀、智能庫門2個應用場景為例,其拓撲結(jié)構(gòu)如圖5、圖6所示。
圖6 應用場景——智能庫門
用戶界面層負責接收以及解釋用戶的輸入指令,向用戶展示輸出結(jié)果,并向業(yè)務(wù)應用層或者業(yè)務(wù)邏輯層發(fā)送用戶指令。該層負責確保接收的數(shù)據(jù)信息的正確性、有效性以及界面樣式,應呈現(xiàn)用戶所需的各類實時數(shù)據(jù),包括故障信息、統(tǒng)計結(jié)果、運維分析結(jié)果等。
智能運維平臺前端開發(fā)采用LayUI框架,后端語言采用PHP語言,使用thinkPHP5.0框架,數(shù)據(jù)庫采用MySQL。綜合分析智能運維平臺的13大模塊,為提供高性能的數(shù)據(jù)快速訪問,對常用基本不變的數(shù)據(jù)采用文件緩存技術(shù),將標準中心模塊、人員管理模塊、系統(tǒng)管理模塊內(nèi)的數(shù)據(jù)存儲成cache文件,通過程序腳本定時存儲、定時更新,保證數(shù)據(jù)的完整性。其他模塊的數(shù)據(jù)則使用內(nèi)存緩存技術(shù),主要使用Redis、Mwmcached緩存系統(tǒng),用于動態(tài)Web應用以減輕數(shù)據(jù)庫負載。平臺運行環(huán)境采用LINUX操作系統(tǒng)搭建,相對Windows操作系統(tǒng)性能更佳,安全性能更好。
通過對最新的中鐵電氣化局第一工程有限公司智能運維平臺項目的調(diào)研實踐,詳細闡述了構(gòu)建智能運維平臺遇到的難點、解決思路及實施方案,構(gòu)建了基于自律分散系統(tǒng)理論的智能運維平臺,采用分層架構(gòu)設(shè)計,降低了層與層之間的耦合、代碼之間的耦合,針對未來客戶的需求變更,只需付出最小的代價對代碼進行修改,為平臺的實現(xiàn)做好了準備,同時也為未來平臺交互采集與數(shù)據(jù)分享打下了堅實的基礎(chǔ)。