通信學(xué)論文-計算機系統(tǒng)分析員論文-通信業(yè)應(yīng)用.doc

通信學(xué)論文-計算機系統(tǒng)分析員論文-通信業(yè)應(yīng)用【摘要】近年來，在應(yīng)用需求的強大驅(qū)動下，我國通信業(yè)有了長足的進步?，F(xiàn)有通信行業(yè)中的許多企業(yè)單位，如電信公司或移動集團，其信息系統(tǒng)的主要特征之一是對線路的實時監(jiān)控要求很高，數(shù)據(jù)量龐大，如何將實時控制與信息系統(tǒng)集成在一起便成為系統(tǒng)實施的一個關(guān)鍵部分。在參與了某個通信公司的一套網(wǎng)管系統(tǒng)以及決策支持系統(tǒng)的設(shè)計后，我們分析了兩者的集成與應(yīng)用工作，深切地感受到有一個良好的設(shè)計策略以及重視所選用的工具是一個關(guān)鍵。這個項目主要是對下屬各分站的子網(wǎng)以及有關(guān)鏈路的連通情況進行實時監(jiān)控、實現(xiàn)報警、路由控制和授權(quán)等功能，其關(guān)鍵在于提供一個實時顯示情況的地圖界面，井將數(shù)據(jù)匯總和組織，建立起數(shù)據(jù)倉庫以及進一步實施數(shù)據(jù)挖掘分析，從而能支持企業(yè)的決策分析。我作為設(shè)計人員之一，著重在本文中討論控制系統(tǒng)與信息系統(tǒng)集成時的策略。【正文】眾所周知，通信行業(yè)需要有一整套監(jiān)控通信網(wǎng)絡(luò)的手段，其工作特點是涉及到的各分站與基站的在地理位置L的分布性，更加需要有在更高一級提供檢測不同分站鏈接情況的手段。一般來講，由于數(shù)據(jù)都是海量的，所以，如何將整個網(wǎng)絡(luò)系統(tǒng)所得的數(shù)據(jù)及時處理，以便和決策部門的分析相結(jié)合，也成為迫切需要解決的重要課題。簡言之，分布性、實時性以及數(shù)據(jù)海量性是解決整個系統(tǒng)設(shè)計和集成的核心問題。首先，讓我們來討論一下“網(wǎng)管監(jiān)控系統(tǒng)”。由于我參與設(shè)計與開發(fā)的這個系統(tǒng)并不是位于基層的分站，其定位在將下屬各分站的主機通信數(shù)據(jù)（包括數(shù)據(jù)流量、鏈路負荷、通往其他結(jié)點即主機的連通情況等）加以收集，所以對于具體通信事務(wù)的底層操作要求并不很高?？紤]到上述原因，我們采用了一個地理信息系統(tǒng)開發(fā)平臺Mapinfo并采用Delphi編程，后臺用SQLServer數(shù)據(jù)庫（這是由于考慮到?jīng)Q策所需要用到的是Microsoft公司的OLAPService）。在分析和計劃之前，我們先對ITU801標準做了詳細的探討，這只是一個有關(guān)子網(wǎng)和鏈路定義以及分層等描述的標準，在聽取了許多分站人員的建議后，將MAPINFO公司提供的一個相關(guān)的MAPX的ActiveX控件嵌入到Delphi程序中，利用MAPX中提供的豐富的類以及操作，比如Object、Layer等實現(xiàn)網(wǎng)管界面，井且加入了子網(wǎng)和鏈路的概念，對屬下的分站可以隨意地組合成為不同子網(wǎng)，而且實現(xiàn)了放大與縮小的功能，大致可以將整個地區(qū)的分站集中在一張地圖中，能顯示在屏幕上，這時，只是顯示出各個分站的概要，小到可以顯示出某臺主機的機柜、機柜直到插件板（因為這些都要實時監(jiān)控）。我們采用了分層的方法來實現(xiàn)以上縮放。對于一些靜態(tài)的數(shù)據(jù)，如分站，主機的位置等則先用Mapinfo公司提供的一套編制地理信息的工具（MAPX是其提供給編程工具的一個ActiveX控件）做成靜態(tài)的層次圖放置于數(shù)據(jù)庫中。我們新做成的這套系統(tǒng)通過與各分站的專用線路加以連接，能實時地得到數(shù)據(jù)，顯示于地圖上，反映出各站、各子網(wǎng)、各鏈路的實時狀態(tài)，并能將控制命令傳回分站（如強制鏈路中斷、路由轉(zhuǎn)換等）?，F(xiàn)在，讓我們來討論其中最為關(guān)鍵的問題，即是要將實時控制系統(tǒng)與企業(yè)信息系統(tǒng)加以集成，我們的設(shè)想和體系結(jié)構(gòu)大體上可以用一張簡圖表示。在這個體系結(jié)構(gòu)中，由各分站保留著詳細的數(shù)據(jù)，網(wǎng)管系統(tǒng)則在一定時間間隔內(nèi)將匯總到的數(shù)據(jù)作少量統(tǒng)計，抽取其中需要保存的內(nèi)容放入數(shù)據(jù)庫，如每分鐘流量，某分站與其他分站每分鐘通信流量，在該分站中某個鏈路的負荷（這些鏈路有可能是動態(tài)分配的，也可能是固定分站之間的通信鏈路）。盡管如此，數(shù)據(jù)仍然是海量的，因此，如果要把這些數(shù)據(jù)都直接送到各個決策部門，比如送給市場部門是不現(xiàn)實的。所以，我們在數(shù)據(jù)庫的基礎(chǔ)上建立了數(shù)據(jù)倉庫，確定了客戶、時間、通信量、計費和故障等幾個數(shù)據(jù)倉庫的主題，每隔一定時間對數(shù)據(jù)庫中的原始數(shù)據(jù)進行清理與抽取等預(yù)處理工作，建立好數(shù)據(jù)倉庫。這里的預(yù)處理包括了許多方面的內(nèi)容，比如有建立計算時間，但是無計費的（計費值為零）的數(shù)據(jù)，應(yīng)視為建立失敗的無效數(shù)據(jù)，需要予以剔除；某些企業(yè)租用的是專用線路按月計費，中間的通信因此無計費的一些有關(guān)記錄也應(yīng)剔除等。在預(yù)處理之后，再利用OLAPService的分析將數(shù)據(jù)融合與匯總。按照決策部門的需要提供相應(yīng)數(shù)據(jù)（比如：市場部門需要每一分站的收益，客戶分布情況以及客戶費用等）。這些都可以由OLAPService對數(shù)據(jù)作預(yù)先處理，此時處理完的數(shù)據(jù)在邏輯上是以立方體（CUBE）形式存在的，其占用的存儲空間便能顯著地降低，如1999年8月有2000萬條通訊記錄，即使形成作為備份的文本都需要4G空間，經(jīng)過OLAPService處理后僅需200M左右空間，因此，經(jīng)處理后的數(shù)據(jù)主要存放于另外的相關(guān)部門的機器中，而不能與主服務(wù)器放在一起。最后，再來討論由決策人員所使用的系統(tǒng)。由于這些部門并不分散，我們就沒有采用OLAPServce的Web發(fā)布方案。采用Delphi編制了訪問OLAPService的客戶端軟件，用了OLAPService提供的、CubeBrowser控件，用相似于網(wǎng)頁的界面提供了數(shù)據(jù)立方體的各種操作，如上鉆（觀察角度從月轉(zhuǎn)到季度甚至年），切片，旋轉(zhuǎn)等操作。為了便于輸出打印數(shù)據(jù)，還內(nèi)嵌了Microsoft的Excel數(shù)據(jù)透視表，可以將在CubeBrowser上所看到的數(shù)據(jù)轉(zhuǎn)化為Excel的表格形式，或者轉(zhuǎn)換成餅形圖、柱形圖和曲線圖等，比如可以觀察每天24小時通信流量的分布曲線圖，可以發(fā)現(xiàn)在夜間12點以后明顯通信流量減少，而決策部門便可制定某些優(yōu)惠或減價措施吸引更多客戶在12點之后使用網(wǎng)絡(luò)。另外，在采用OLAPService中的數(shù)據(jù)挖掘功能時，其中提供的兩類算法分別是基于決策樹的分類和基于決策樹的聚類，市場部門的聚類算法將客戶根據(jù)費用情況加以聚集，以期發(fā)現(xiàn)處于同一消費水平的客戶的共同特征，便于制定政策，吸引客戶。這方面的努力我們將會進一步持續(xù)進行，以保證有足夠的海量數(shù)據(jù)而發(fā)現(xiàn)其中的規(guī)律。整個系統(tǒng)運行后，其數(shù)據(jù)采集，數(shù)據(jù)處理等一系列工作都由程序定期地自動進行，該系統(tǒng)應(yīng)用已有一段時間，受到了不少好評。當(dāng)然，也發(fā)現(xiàn)了其中有不少問題，比如；主服務(wù)器數(shù)據(jù)庫的容量問題，主站與分站的通信效率問題，還有在網(wǎng)管系統(tǒng)中，網(wǎng)絡(luò)故障的確定還不夠細致，需要由分站再具體化加以確定，決策系統(tǒng)與網(wǎng)管系統(tǒng)之間還缺少直接通信手段等，這些都有待于進一步的解決與改進。實時控制系統(tǒng)與企業(yè)信息系統(tǒng)集成化是推動從事生產(chǎn)制造、測量與監(jiān)控等業(yè)務(wù)的企事業(yè)單位真正邁向信息化，提高工作效率的一個重要動力。如果是大型企業(yè)，更需要有一整套的系統(tǒng)，支持Web發(fā)布，智能查詢，自動識別如用于故障預(yù)測和數(shù)據(jù)挖掘等技術(shù)，從而能夠?qū)⒌讓拥膶崟r監(jiān)控與高層的