智能巡檢平臺研發(fā)._第1頁
智能巡檢平臺研發(fā)._第2頁
智能巡檢平臺研發(fā)._第3頁
智能巡檢平臺研發(fā)._第4頁
智能巡檢平臺研發(fā)._第5頁
已閱讀5頁,還剩35頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、2012年8月小 組:網絡啄木鳥QC小組課題類型:創(chuàng)新型發(fā) 表 人:北京移動網運中心 小組名稱網絡啄木鳥QC小組成立時間2008年12月課題類型創(chuàng)新型課題名稱智能巡檢平臺研發(fā)活動時間2011年1月-2012年1月活動次數(shù)25小組人數(shù)9出席率96%序號姓名性別小組分工職稱職責1臧志勇男顧問工程師活動指導2何嫚女顧問工程師活動指導3郭旗男顧問工程師活動指導4宗建菲男顧問工程師活動指導5劉春燕女組長,QC小組活動國家級診斷師,國優(yōu)獲得者工程師方案制定,組織實施6劉磊男組員工程師方案制定,組織實施7劉彥挺男組員工程師方案制定,具體實施8陳恕男組員工程師方案制定,具體實施9何媛女組員工程師方案制定,具體

2、實施23計劃時間實際時間時間:2011年1月第1-2次小組會議制定活動計劃表,制表人:劉春燕4電子運行維護系統(tǒng)(EOMS) : 實現(xiàn)公司相關管理流程的信息化落地,是管理、維護人員日常工單處理的支撐平臺。集中運行維護平臺: 通過指令接口完成網管系統(tǒng)對網絡配置信息、主動監(jiān)控指標、實時信息的查詢等操作,實現(xiàn)各類網元指令統(tǒng)一下發(fā)、采集、分析、處理。 綜合告警平臺: 通過接入各類網元告警信息,實現(xiàn)通信網絡告警的統(tǒng)一采集、統(tǒng)一關聯(lián)、統(tǒng)一呈現(xiàn),統(tǒng)一派單。5 隨著通信市場競爭的日趨激烈,網絡質量已成為保障客戶感知的生命線,其戰(zhàn)略地位尤為重要。同時,網絡管理也正向集中化、一體化逐漸演進。 宏 觀 環(huán) 境網 絡

3、質 量競爭對手 “攜號轉網”這項惠民政策的開展,使北京移動面臨比之前更大的市場競爭壓力,同時也對網絡安全也提出了更高的要求??蛻舾兄?2011年中國移動將提升客戶感知作為改善網絡質量的指導方向,繼續(xù)發(fā)揮“網絡質量大會戰(zhàn)”的重要作用。 李躍總裁在網絡工作會上指出:“實現(xiàn)全網質量全面領先競爭對手,建立起集中監(jiān)控、集中網管、集中維護、集中優(yōu)化的現(xiàn)代化維護體系。 北京公司領導在網絡工作會上指出:要“創(chuàng)新網絡管理,推進 “一體化”維護。戰(zhàn)略規(guī)劃6網運中心預防性維護故障處理網絡優(yōu)化投訴處理網絡建設27個局點2000余萬用戶10000余臺設備皂君廟區(qū)域西客站區(qū)域望京區(qū)域幸福區(qū)域 網運中心作為北京移動通信網核

4、心網絡的維護部門,保障著移動通信網的安全、穩(wěn)定、高效的運行,同時也是公司的日常運營收入重要保證。而核心交換設備承載著數(shù)十萬的交換任務,因此關系客戶感知的核心設備的預防性維護就成為我們工作中的重中之重。7序號問題未發(fā)現(xiàn)原因發(fā)生頻數(shù)(12個月累計)頻率%維護項目手工查詢工作量大、易出錯維護項目執(zhí)行不及時維護項目不能確保每項核查維護項目不能確保有專人處理合計97100 小組對2010年下半年預防性維護問題發(fā)現(xiàn)情況進行了統(tǒng)計分析,得出目前的網絡預防性維護方式不能完全及時準確地發(fā)現(xiàn)網絡安全隱患。1、每天耗時150余人時,出錯數(shù)由年初月均3件上升為年底月均5件。010年初年底3、近1%的維護項目不能確保每

5、項核查。2、不能及時處理呈上升趨勢。01013579 114、有3%的維護項目無專人負責。時間:2011年3月第34次小組維護作業(yè)計劃現(xiàn)狀進行分析并歸納原因,制表人:劉春燕故障隱患發(fā)現(xiàn)率在98%左右98%98%97%99%97%99%96%97%97%98%98%99%99%100%2010年7月2010年8月2010年9月2010年10月2010年11月2010年12月84000余項日例行維護作業(yè)計劃余項日例行維護作業(yè)計劃500臺核心網設備臺核心網設備12名維護人員名維護人員4個維護組個維護組14654.7554.7536.5統(tǒng)計一年的例行維護作業(yè)計劃數(shù)量(單位:萬)日例行周例行月例行季例行

6、時間:2011年2月第34次小組維護作業(yè)計劃現(xiàn)狀進行分析并歸納原因,制表人:劉春燕新 從左圖我們可以看出一年的日例行維護作業(yè)計劃多達146萬項,但我們的實際維護手段還主要停留在手動執(zhí)行命令及通過小程序半自動執(zhí)行的混合狀態(tài),手動執(zhí)行效率低下,存在人為疏忽和遺忘,通過半自動工具手段也無法保證預防性工作的準確及時運行。9預防性維護HLRSGSNMGWMSSCDS全新智能化維護模式時間:2011年3月第5次小組設定課題目標,制表人:劉春燕小組決定開發(fā)一種全新智能化維護模式,達到及時發(fā)現(xiàn)故障、提高維護效率、確保審計效力的目的。經過小組討論決定本次QC活動針對最重要的五類網元(HLR、SGSN、MGW、M

7、SS、CDS)進行試點。10故障隱患發(fā)現(xiàn)率工作量v 針對提升預防性維護工作的迫切需求,小組成員運用“頭腦風暴法”提出了11個想法。并通過親和圖進行繪制整理:11使用現(xiàn)有半自動化工具對現(xiàn)有工具進行優(yōu)化開發(fā)周期短業(yè)務有變更后快速修改根據現(xiàn)有情況定制開發(fā)靈活度高基于區(qū)域的分散式開發(fā)解決方案集中操作維護平臺已經實現(xiàn)到各網元的通道可通過EOMS故障工單的方式督促專人處理可以利用現(xiàn)有網管系統(tǒng)無需新購硬件設備綜合告警平臺與EOMS已開發(fā)完成相應接口提供整體的解決方案基于網管的集中式開發(fā)解決方案可利用多套網管系統(tǒng)進行聯(lián)動開發(fā)將預防性維護內容納入統(tǒng)一的故障管理開發(fā)完成后的平臺有專人維護時間:2011年4月第6次

8、小組會議成員頭腦風暴利用親和圖歸納總體方案,制圖人:劉彥挺12我們通過使用親和圖法,提出了兩種解決方案:時間:2011年4月第6次小組會議成員頭腦風暴利用親和圖歸納總體方案,制圖人:劉彥挺13指標較好指標適中指標較差需求滿足開發(fā)實現(xiàn)維護保障時間:2011年4月第7-8次小組會議對兩個總體方案進行對比討論,制圖人:劉彥挺100%滿足現(xiàn)有維護作業(yè)計劃100%滿足現(xiàn)有維護作業(yè)計劃平均變更實現(xiàn)時間為1天平均變更實現(xiàn)時間為3天預計開發(fā)2個月預計開發(fā)1個月需自主開發(fā),實現(xiàn)較困難需自主開發(fā),實現(xiàn)較困難目前網管系統(tǒng)已經實現(xiàn)目前網管已有派單接口,需進行少量修改即可滿足由于缺少專業(yè)測試,可用性較差,年平均系統(tǒng)可用

9、性為:98%由開發(fā)人員進行監(jiān)控維護,故障監(jiān)控率為58.33%由于擁有專業(yè)測試,可用性較高,年平均系統(tǒng)可用性為:99.9%由專業(yè)的維護人員進行7*24監(jiān)控,故障監(jiān)控率為100%對比項基于區(qū)域的分布式解決方案基于網管的集中式解決方案對現(xiàn)有巡檢任務的契合度智能巡檢變更的靈活度開發(fā)周期是否方便與綜合告警對接是否能夠進行故障派單系統(tǒng)可用性系統(tǒng)維護性14 小組在確定總體方案后,根據目前網管系統(tǒng)對各業(yè)務系統(tǒng)的運行狀態(tài)提供多種支撐方式,可根據具體運維流程需要進行靈活的組合分配,滿足預防性維護工作的各種要求。具體細化方案如下:時間:2011年5月第9-11次小組會議討論細化方案并進行試驗,制圖人:劉磊15 集中

10、運行維護平臺維護人員網元 1. 集中運行維護平臺通過網管系統(tǒng)向網元發(fā)送指令并采集返回的報文結果。 2. 維護人員直接登錄集中運行維護平臺對全部日例行維護作業(yè)計劃項目進行查看和審核,并根據異常結果來處理故障。01010100101010時間:2011年5月第9-11次小組會議討論細化方案并進行試驗,制圖人:劉磊16測試方案測試過程 測試網元BJGS04 執(zhí)行項目數(shù)量10 返回報文時間2min 報文呈現(xiàn)時間10s 維護人員檢查時間 8min添加網元 添加任務 任務執(zhí)行執(zhí)行結果彈出報告 日例行維護作業(yè)計劃的執(zhí)行實現(xiàn)了自動化。 返回結果和呈現(xiàn)報告的時間都很短。X 極大的縮短了之前人工執(zhí)行指令的操作時間

11、,但是人工審核報告還需要一定的時間。一個網元10項維護作業(yè)計劃審核=8分鐘,全網500余臺設備進行遍歷=500*8min=67小時結果分析人工審核時間:2011年5月第9-11次小組會議討論細化方案并進行試驗,制圖人:劉磊17 1. 集中運行維護平臺自動完成報文結果的審核,對異常項目生成智能巡檢告警送至綜合告警平臺。 2. 由專門的監(jiān)控人員分析綜合告警平臺上生成的維護作業(yè)計劃告警信息。 3. 監(jiān)控人員派發(fā)EOMS故障工單給相應區(qū)域的維護人員,維護人員根據故障工單來處理故障。網元 集中運行維護平臺 綜合告警平臺01010100101010維護人員監(jiān)控人員故障工單告警信息智能巡檢告警時間:2011

12、年5月第9-11次小組會議討論細化方案并進行試驗,制圖人:劉磊智能巡檢告警18測試方案測試過程 測試網元 BJGS04 執(zhí)行項目數(shù)量 10 返回報文時間 2min 報文呈現(xiàn)時間 10s 派發(fā)智能巡檢告警 30s 綜合告警平臺分析告警 生成告警信息 10s 監(jiān)控人員分析告警 1min 監(jiān)控人員派發(fā)故障工單 2min 維護人員分析故障工單 1min 對日例行維護作業(yè)計劃的執(zhí)行和審核都實現(xiàn)了自動化,不需要維護人員遍歷全部項目。 由綜合告警平臺分析智能巡檢告警只需要10s的時間,極大的壓縮了維護人員審核時間。X 但是監(jiān)控人員對告警的分析、派單等還是人工執(zhí)行,需要一定的時間。假定全網500臺設備每天有5

13、00個告警(合理假設),監(jiān)控人員需要用時(1+2+1)min*500=33小時結果分析派發(fā)故障工單綜合告警平臺監(jiān)控人員人工派單時間:2011年5月第9-11次小組會議討論細化方案并進行試驗,制圖人:劉磊19 1. 集中運行維護平臺自動完成報文結果的審核,對異常項目生成智能巡檢告警送至綜合告警平臺,綜合告警平臺自動完成對告警信息的分析并送至EOMS平臺。 2. EOMS平臺根據告警信息自動生成維護作業(yè)計劃告警工單,維護人員根據故障工單來處理故障。網元 集中運行維護平臺 綜合告警平臺01010100101010告警信息智能巡檢告警EOMS平臺維護人員自動派發(fā)故障工單時間:2011年5月第9-11次

14、小組會議討論細化方案并進行試驗,制圖人:劉磊20測試方案測試過程 對日例行維護作業(yè)計劃的執(zhí)行和審核都實現(xiàn)了自動化。 實現(xiàn)了告警信息分析和派發(fā)工單的自動化,真正實現(xiàn)了智能巡檢平臺由執(zhí)行指令、分析結果到生成告警信息、派發(fā)工單的全程自動化。 省去了監(jiān)控人員分析告警、派單等人工操作的步驟,由原來的3min壓縮到了20s,現(xiàn)在維護人員對告警的處理只需要(1min+20s)*500=11小時結果分析 測試網元 BJGS04 執(zhí)行項目數(shù)量 10 返回報文時間 2min 報文呈現(xiàn)時間 10s 派發(fā)智能巡檢告警 30s 綜合告警平臺分析告警 生成告警信息 10s 派發(fā)告警信息至EOMS平臺 10s EOMS平臺

15、生成維護作業(yè) 計劃告警工單 10s 維護人員分析告警工單 1min結論:最佳方案!智能巡檢告警派發(fā)故障工單綜合告警平臺自動派單EOMS平臺時間:2011年5月第9-11次小組會議討論細化方案并進行試驗,制圖人:劉磊21A0A1A2A3ZB1B2C1C2D1D2時間:2011年6月第12次小組會議討論確定處理流程,制圖人:劉磊22時間:2011年6月第12次小組會議討論確定開發(fā)模塊,制圖人:劉磊23時間:2011年7月第13次小組會議討論確定對策表,制圖人:劉彥挺項目對策目標措施負責人地點完成日期模塊1開發(fā)集中運行維護平臺的數(shù)據采集接口及參數(shù)優(yōu)化數(shù)據采集的成功率達到99.9%以上開發(fā)數(shù)據采集接口

16、用正交法選擇最優(yōu)的接口參數(shù)組合。劉彥挺菜市口13層會議室2011-07-31模塊2使用Java Script編寫腳本,移植人機命令并開發(fā)命令腳本的模板完成所有日例行維護作業(yè)計劃的操作指令的移植,實現(xiàn)100%覆蓋率編寫符合智能巡檢平臺要求的巡檢任務腳本,涵蓋所有網元類型的所有日例行維護作業(yè)計劃項目劉磊菜市口13層會議室2011-08-31模塊3添加巡檢方案,按照集團公司要求完成任務調度完成所有維護項目的模板制作和方案下發(fā),完成全部日例行任務的調度。創(chuàng)建維護項目的模板,選擇要下發(fā)的模板和網元建立方案。系統(tǒng)將自動生成元任務,根據集團規(guī)范要求完成巡檢任務調度劉春燕菜市口13層會議室2011-08-31

17、模塊4集中運行維護平臺與綜合告警平臺進行聯(lián)調,實現(xiàn)巡檢任務觸發(fā)告警信息綜合告警平臺能夠自動完成告警分析、生成相應的告警信息制作智能巡檢平臺與綜合告警平臺的接口,以使綜合告警平臺能夠分析集中運行維護平臺根據巡檢任務腳本制定的規(guī)則產生的告警劉彥挺菜市口13層會議室2011-08-31模塊5 針對智能巡檢告警,實現(xiàn)EOMS平臺的自動派單EOMS接受綜合告警發(fā)來的告警信息,產生告警工單并派發(fā)到指定賬號綜合告警平臺與EOMS平臺間的接口已存在可直接使用,需要針對巡檢任務指定專門的派單賬號及告警工單流轉、處理流程規(guī)則建立智能巡檢工單的短信提醒 陳恕菜市口15層綜合網管中心2011-08-3124添加巡檢方

18、案,完成任務調度模塊模塊1 1模塊模塊2 2模塊模塊3 3模塊模塊4 4模塊模塊5 5分析智能巡檢告警,自動生成告警信息根據告警信息,自動派發(fā)EOMS告警工單移植操作指令,開發(fā)命令腳本模板數(shù)據采集接口開發(fā)與調整對策 開發(fā)集中運行維護平臺的數(shù)據采集接口及參數(shù)優(yōu)化實施 2011年7月31日完成集中運行維護平臺上數(shù)據采集接口的開發(fā),為了保證集中運行維護平臺數(shù)據采集的成功率,我們使用正交實驗法進行測試,找出最優(yōu)的參數(shù)組合。實驗情況1.制定因素位級表因素連接網元并發(fā)數(shù)A(個)指令下發(fā)間隔時間B(秒)失敗后重復連接次數(shù)C(個)位級110201位級220403位級3306052.因素說明表因素說明連接網元并

19、發(fā)數(shù)A(個)同時連接網元的數(shù)量。連接數(shù)量過少會導致數(shù)據采集的效率低;連接數(shù)量過多會導致集中運行維護平臺負荷過高。指令下發(fā)間隔時間B(秒)采集數(shù)據時下發(fā)指令的時間間隔。間隔時間過短會導致采集數(shù)據的遺漏;時間過長會導致數(shù)據采集的時延過大。失敗后重新連接次數(shù)C(個)數(shù)據采集失敗后重復連接網元的次數(shù)。重復連接數(shù)過少會導致采集數(shù)據的遺漏,重復連接數(shù)過多,會導致數(shù)據采集的時延過大。時間:2011年7-9月第14-20次小組會議進行實施階段分析及總結,制圖人:劉磊25添加巡檢方案,完成任務調度分析智能巡檢告警,自動生成告警信息根據告警信息,自動派發(fā)EOMS告警工單移植操作指令,開發(fā)命令腳本模板數(shù)據采集接口開

20、發(fā)與調整實驗情況 因素 實驗號連接網元并發(fā)數(shù)A(個)指令下發(fā)間隔時間B(秒)失敗后重復連接次數(shù)C(個)數(shù)據采集成功率(%)11(10)1(20)398.322(20)1199.133(30)1299.8412(40)299.9522399.6632199.3713(60)1(3)98.78232(5)98.99333(8)99.1I=位級1之和296.9297.2297.1I+II+III=892.7II=位級2之和297.6298.8298.6III=位級3之和298.2296.7297.0極差R=I、II、III中,大數(shù)-小數(shù)1.32.11.63.設計實驗方案模塊模塊1 1模塊模塊2 2模

21、塊模塊3 3模塊模塊4 4模塊模塊5 5時間:2011年7-9月第14-20次小組會議進行實施階段分析及總結,制圖人:劉磊26添加巡檢方案,完成任務調度分析智能巡檢告警,自動生成告警信息移植操作指令,開發(fā)命令腳本模板數(shù)據采集接口開發(fā)與調整實驗情況4.實驗結果分析“直接看,可靠又方便”:直接比較9個實驗的成功率,容易看出,第4號的數(shù)據采集成功率最高 為99.9%,“直接看”的好條件為A1B2C2?!八阋凰悖行в趾唵巍保喊凑瘴患壷驮酱髼l件越好,我們得出“算一算”的好條件為A3B2C2。小組成員在7月18日-7月22日對“直接看”和“算一算”的好條件分別進行了批量實驗。7月18日7月19日7月2

22、0日7月21日7月22日平均值直接看100%99.9%99.8%100%99.8%99.9%算一算99.8%99.8%99.9%99.9%99.6%99.8% 根據批量時間結果,我們可以看出,”直接看”好條件的平均成功率為99.9%,”算一算”好條件的平均成功率為99.8%,在集中運行維護平臺數(shù)據采集接口開發(fā)中,我們根據實驗結果和實際情況選擇“A1B2C2”的好條件,即連接網元并發(fā)數(shù)為10個,指令下發(fā)間隔時間為40秒,失敗后重復連接次數(shù)為3次。在集中運行維護平臺成功完成了數(shù)據采集接口的開發(fā),通過正交實驗,選擇出了最優(yōu)的參數(shù)組合,可將數(shù)據采集的平均成功率保持在99.9%。效果確認時間:7月23日

23、-7月25日模塊模塊1 1模塊模塊2 2模塊模塊3 3模塊模塊4 4模塊模塊5 5根據告警信息,自動派發(fā)EOMS告警工單時間:2011年7-9月第14-20次小組會議進行實施階段分析及總結,制圖人:劉磊27添加巡檢方案,完成任務調度分析智能巡檢告警,自動生成告警信息移植操作指令,開發(fā)命令腳本模板數(shù)據采集接口開發(fā)與調整對策 使用Java Script編寫腳本,移植人機命令并開發(fā)命令腳本的模板實施 截至2011年8月31日,完成HLR、SGSN、MGW、MSS和CDS的腳本編寫工作,并完成全部網元所有日例行維護作業(yè)計劃的命令腳本共計49個模板。腳本編程實現(xiàn)。應用情況051015HLRSGSNMGW

24、MSSCDS開發(fā)的腳本數(shù)量日例行維護作業(yè)計劃中100%的項目完成腳本的測試。制作完成全部5類網元所有日例行維護作業(yè)計劃的命令腳本的模板。效果確認時間:9月1日-9月3日模塊模塊1 1模塊模塊2 2模塊模塊3 3模塊模塊4 4模塊模塊5 5根據告警信息,自動派發(fā)EOMS告警工單時間:2011年7-9月第14-20次小組會議進行實施階段分析及總結,制圖人:劉磊28添加巡檢方案,完成任務調度分析智能巡檢告警,自動生成告警信息移植操作指令,開發(fā)命令腳本模板數(shù)據采集接口開發(fā)與調整對策 添加巡檢方案,按照集團公司要求完成任務調度實施 根據需要下發(fā)的模板和巡檢網元建立巡檢方案,集中運行維護平臺自動生成相應的

25、元任務,根據集團下發(fā)的設備維護細則完成所有元任務的調度工作。截至2011年8月31日,完成了全部5類網元所有日例行維護作業(yè)計劃共計155項元任務的調度工作。腳本編程實現(xiàn)。應用情況 完成了集中運行維護平臺上所有元任務的建立和調度工作,實現(xiàn)了日例行維護作業(yè)計劃項目100%的覆蓋率。效果確認時間:9月1日-9月3日模塊模塊1 1模塊模塊2 2模塊模塊3 3模塊模塊4 4模塊模塊5 5根據告警信息,自動派發(fā)EOMS告警工單時間:2011年7-9月第14-20次小組會議進行實施階段分析及總結,制圖人:劉磊29添加巡檢方案,完成任務調度分析智能巡檢告警,自動生成告警信息移植操作指令,開發(fā)命令腳本模板數(shù)據采

26、集接口開發(fā)與調整對策 集中運行維護平臺與綜合告警平臺進行聯(lián)調,實現(xiàn)巡檢任務觸發(fā)告警信息實施 截至2011年8月31日,完成集中運行維護平臺與綜合告警平臺的聯(lián)調,利用告警解析腳本的規(guī)則產生的智能巡檢告警(包含告警號)送至綜合告警平臺分析,觸發(fā)綜合告警平臺自動生成標準告警信息。腳本編程實現(xiàn)。應用情況完成集中運行維護平臺上告警解析腳本開發(fā),并實現(xiàn)了與綜合告警平臺的連接,成功將智能巡檢告警送至綜合告警平臺進行分析,正確生成告警信息。效果確認時間:9月1日-9月3日 綜合告警平臺綜合告警平臺生成告警號送往 綜合告警平臺模塊模塊1 1模塊模塊2 2模塊模塊3 3模塊模塊4 4模塊模塊5 5根據告警信息,自

27、動派發(fā)EOMS告警工單 分析告警號 生成標準告警信息時間:2011年7-9月第14-20次小組會議進行實施階段分析及總結,制圖人:劉磊30添加巡檢方案,完成任務調度分析智能巡檢告警,自動生成告警信息移植操作指令,開發(fā)命令腳本模板數(shù)據采集接口開發(fā)與調整對策 針對智能巡檢告警,實現(xiàn)EOMS平臺的自動派單實施 截至2011年8月31日,實現(xiàn)了HLR、SGSN、MGW、MSS和CDS全部網元的智能巡檢上線工作,完成了100%覆蓋集團要求的日例行維護作業(yè)計劃,對于異常項目集中運行維護平臺將智能巡檢告警送至綜合告警平臺分析,并生成告警信息,EOMS平臺根據告警信息自動派發(fā)EOMS告警工單。腳本編程實現(xiàn)。應

28、用情況 EOMS平臺根據綜合告警平臺送來的告警信息,及時將維護作業(yè)計劃告警工單派發(fā)至相應的EOMS賬號下,并可以短信提醒相關的維護人員。效果確認時間:9月1日-9月3日模塊模塊1 1模塊模塊2 2模塊模塊3 3模塊模塊4 4模塊模塊5 5根據告警信息,自動派發(fā)EOMS告警工單收到維護作業(yè)計劃告警工單,工單號:ID-3161-111226-00167,主題:SCCP子系統(tǒng)狀態(tài)異常時間:2011年7-9月第14-20次小組會議進行實施階段分析及總結,制圖人:劉磊3197%99%98%100%100%100%95%96%97%98%99%100%9.20-10.1910.20-11.1911.20-

29、12.19手工執(zhí)行方式智能巡檢方式 9月20日-12月19日期間智能巡檢方式和手工執(zhí)行方式并行執(zhí)行,通過上述分析,我們可以得出: 采用手工執(zhí)行方式完成預防性維護工作,無法保證所有設備的故障隱患發(fā)現(xiàn)率都達到100%。 采用智能巡檢平臺完成預防性維護工作,HLR、SGSN、MSS、MGW和CDS均能實現(xiàn)100%預防性維護故障隱患發(fā)現(xiàn)率。01010100101010網元1212.412.212.512.212.56.096.226.42024681012146.20-7.197.20-8.198.20-9.199.20-10.1910.20-11.1911.20-12.19日工時統(tǒng)計(6.20-12

30、.19)手工執(zhí)行日工時智能巡檢日工時 從上表可以看出9月20日-12月19日期間,采用智能巡檢平臺完成預防性維護工作,平均日工時從之前三個月的12.2小時降低到了6.24小時,維護效率提高了 (12.2-6.24)/12.2*100%=47.5%。而在9月20日-12月19日期間平均日工時也從手工執(zhí)行方式的12.4小時降低智能巡檢方式的6.24小時,維護效率提高了 (12.4-6.24)/12.4*100%=49.6%。32時間段時間段人工人工 執(zhí)執(zhí)行行 日工日工時時人工人工執(zhí)行執(zhí)行 平均日工平均日工時時智能智能 巡檢巡檢 日工日工時時智能智能 巡檢巡檢 平均日工平均日工時時6.20-7.191212.2-7.20-8.1912.4-8.20-9.1912.2-9.20-10.1912.512.46.096.2410.20-11.1912.26.2

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論