分布式系統設計原則精選(九篇)

前言：一篇好文章的誕生，需要你不斷地搜集資料、整理思路，本站小編為你收集了豐富的分布式系統設計原則主題范文，僅供參考，歡迎閱讀并收藏。

第1篇：分布式系統設計原則范文

【關鍵詞】電商應用 分布式 系統架構 虛擬化 規劃設計

1 系統設計原則與目標分析

分布式計算系統的研究一直是計算機技術領域的一個研究熱點，隨著云計算、虛擬化、物聯網等應用的推廣普及，分布式計算的理論研究也越來越受到研究者的重視。研究分布式計算的數學基礎和理論，揭示與分析分布式系統的底層問題（資源調度、分配、通信、協調、同步及不確定等），研究基本的算法概念與實現技術變得非常重要。

隨著淘寶、京東等電子商務平臺的網絡購物應用的快速發展，使得傳統的網絡服務模式從CS架構向著分布式平臺架構演進。本文針對具有電商類業務應用特點的分布式架構平臺進行分析，提出一種面向電商應用的分布式環境系統架構，以適應快速發展的電子商務應用。

2 電商應用的平臺技術分析

淘寶、京東等電子商務平臺，以及12306鐵路訂票系統等網站，其本質上是一種分布式請求應用，其應用的特點不同于網絡搜索類應用。這類請求通常情況下是數據的實時檢索，而相對應的網絡搜索引擎的檢索結果通常是通過蜘蛛程序預前爬取到的靜態搜索結果。這類電子商務類應用，往往需要與電子商務的支付平臺相連接，其連接需要通過加密的、經過安全認證的網絡連接保證可靠性，可以把該類應用統稱為“電商應用”。這類應用的數據庫系統并不像搜索類業務復雜，但是其數據并發及數據間的協同互鎖問題更重要，安全性、容錯性和并行讀寫的問題更突出。在電子商務平臺有類似優惠促銷活動時，或網絡購票系統定時開放票源的時候，表現出來的大數據量并發訪問，會對系統架構造成較大的沖擊。

本文針對具有電商類業務應用特點的分布式架構開展研究，對其分布式系統的體系架構、資源的分配調度、云端資源的虛擬化調度與配置等問題展開分析。

2.1 技術對比

在現有的分布式技術的理論研究和分析中，對底層資源的分配和調度處理多采用不同的技術手段。并行計算技術的實現通常是一臺計算機，配備有多處理機，多處理機之間進行合作協同計算，最終結果由一臺計算機來處理。分布式計算技術是多網的計算機，有各自的主機和處理器，通過網絡分配共享計算任務和計算信息。云計算則是計算機通過網絡發送計算命令給服務器，讓服務器執行計算任務并將結果返還給發送命令的計算機。從處理對象的關系來看，并行計算是由單個計算機用戶完成的，分布式計算是由多個計算機用戶合作完成的，云計算是沒有用戶直接參與，而是交給網絡另一端的服務器來完成資源的分配與調度。

2.2 平臺分析

分布式環境的開放研究平臺已有很多，比較有代表性的平臺包括Hadoop、BOINC（Berkeley Open Infrastructure for Network Computing）、SETI@home等。其中有代表性的Hadoop架構是在借鑒Google的MapReduce框架體系的基礎上發展起來的。

Hadoop實現了一個分布式文件系統（Hadoop Distributed File System），用戶可以在不了解分布式底層細節的情況下，開發分布式程序。HDFS有著高容錯性的特點，并且設計用來部署在低廉的硬件上，適合那些有著超大數據集（large data set）的應用程序。但在中間處理過程中，系統復雜度較高，map/reduce處理數據時對數據的并發性、互斥性及容錯性考慮不足。本文提出一種新的架構，對于分布式大數據量并行計算的解決方案不同于復雜的hadoop，中間計算結果不依賴于hdfs，使用不同于map/reduce的設計模式解決問題。

3 電商應用的系統平臺設計

3.1 平臺業務流程設計

電子商務解決方案通常分為直銷方案和供應鏈集成方案。直銷方案常用于商業零售，一個商業組織通過虛擬商店來招攬客戶，客戶通過瀏覽器獲得想要的產品。供應鏈集成方案的目標是傳送一個動態的數據流，以實時數據聯系各地的貿易伙伴。為了實現這一目標，所有參與供應鏈解決方案的參加者必須采用統一的數據標準，從而實現數據的流暢和無縫傳輸。

電子商務應用系統提供網上交易和資金轉帳等服務。根據商務規則進行用戶數據處理，定單處理，信息交流，促銷和廣告；對商務數據存儲及檢索，提供目錄管理，安全性管理和通信服務，提供開發組件、企業數據庫等必需的工具。

普通的分布式處理應用一般是顯示事先編寫好的靜態數據，數據變化較小，網頁內容更新速度慢。如搜索引擎業務應用，其搜索結果通常是根據之前其他用戶曾經提交的搜索關鍵詞，由系統預先在后臺通過蜘蛛程序的抓取，在整個互聯網中獲取到有用的頁面數據，該數據經分類處理后保存在google的數據庫系統中，新用戶的搜索過程只是在系統數據庫中將已建立起來的數據關系重新在web頁面呈現。再比如gmail的郵箱服務，由google公司開發的gmail郵箱服務將用戶的郵件保存在不同的分布式存儲系統，用戶的郵件內容更新較慢，數據量較小，這些特點決定了，普通的分布式處理在數據庫的設計過程中并不需要過多的考慮數據的并發性、互斥性及容錯性等特點。

而電子商務類網站不同于普通的分布式應用，其以商務數據處理為主，數據類型復雜，數據流入量大、數據交換頻繁，因此數據庫的運行效率直接影響整個電子商務系統的效率，數據的安全性也直接影響著系統的正常安全運行。

基于以上的分析，可以看到，分布式應用從早期的分布式計算任務分配、發展到分布式數據爬取、再到分布式數據的大規模并行處理，其核心體系架構針對不同的應用，表現出不同的特征。

3.2 平臺架構實現

分布式系統架構設計在性能上要求：

（1）數據分布式存儲。

（2）請求分布式調度。

（3）多結點分布式部署。

（4）雙重備份、熱切換等。

系統設計中最重要的是網絡架構、分布式資源分配及模塊間資源調度通信等問題。本文提出的分布式框架，提供并行計算模式，用于利用多機多核處理器的計算能力；提供分布式緩存用于使用多機內存能力；提供遠程文件操作用于利用遠程多機硬盤存儲能力；提出完整的分布式協同和鎖，用于實現多機的協作和通訊。框架提出簡單易用的API接口，實現對多臺計算機處理器、內存、硬盤的統一利用，從而獲取較大的計算能力解決復雜問題。

設計的架構在系統設置“商”，“生產者”，“倉庫”的幾個核心概念。“生產者”為一個計算節點，可以部署在多個機器，它由開發者實現，計算時，“生產者”到“倉庫”獲取輸入資源，再將計算結果放回“倉庫”返回給“商”。“商”負責承包一個復雜項目的一部分，可以理解為一個分配任務和調度程序，它由開發者自己實現，開發者可以自由控制調度過程，比如按照“生產者”的數量將源數據切分成多少份，然后遠程分配給“生產者”節點進行計算處理，它處理完的中間結果數據不限制保存在hdfs里，而可以自由控制保存在分布式緩存、數據庫、分布式文件里。如果需要結果數據的合并，可以新建立一個“生產者”的任務分配進行完成。多個“生產者”之間進行責任鏈式處理。總的來說，是將大數據的復雜分布式計算，設計為一個鏈式的多“商”環節去處理，每個環節包括利用多臺“生產者”機器進行并行計算，無論是拆分計算任務還是合并結果，都可以設計為一個單獨的“生產者”環節。這樣做的好處是，開發者有更大能力去深入控制并行計算的過程，去保持使用并行計算實現業務邏輯的完整性，而且對各種不同類型的并行計算場景也能靈活處理，不會因為某些特殊場景被map/reduce的框架限制，并且鏈式的每個環節也方便進行監控過程。

對分布式協同方面，簡化樹型結構，用兩層結構取代；簡化回調多線程等待編程模型，用更直觀的容易保證業務邏輯完整性的內容變化事件以及狀態輪循取代；簡化臨時節點和序列節點等類型，取代為在創建節點時是否指定保持心跳，心跳斷掉時節點會自動刪除。系統提出沒有單點問題，可以有任意多個復本，它的復制不是定時而是基于內容變更復制。實現領導者選舉算法，在領導者服務器當機情況下，會自動將請求切換到備份服務器上，選舉出新的領導者。基于該框架可實現分布式配置信息、集群管理、故障節點檢測、分布式鎖、等協同功能。

對文件的處理方面，提供對集群文件的操作支持，包括：

（1）元數據訪問，添加刪除，按塊拆分， 高性能并行讀寫等。

（2）對集群文件的解析支持。

（3）對整形數據的高性能讀寫支持。

（4）兩階段提交和事務補償處理。

4 結束語

本文針對具有電商類業務應用特點的分布式架構平臺進行分析，所設計的系統平臺實現了分布式協同，用兩層結構取代樹型結構，用直觀的保證業務邏輯完整性的內容變化事件以及狀態輪循取代回調多線程等待編程模型。

參考文獻

[1]張麗，劉彥良，季峰. 面向大數據的分布式系統設計關鍵技術研究[J].電子技術與軟件工程，2014（17）：210.

[2]田文洪，趙勇.云計算資源調度管理[M].北京：國防工業出版社，2011.

[3]羅紅，穆德俊，鄧智群等.網格計算中任務資源研究綜述[J].計算機應用研究，2005，5（1）：16-19.

第2篇：分布式系統設計原則范文

關鍵詞：變電站　綜合自動化系統　結構

1、系統結構

1.1　面向間隔的分布式系統

將變電站的輸變電路線分為許多間隔，如進線間隔、變壓器間隔、出線間隔等。各間隔設備相對獨立，僅通過站內通信網絡互聯，并同站級計算機進行通信。每一間隔層按遙測、遙信、遙控、保護等多CPU分布配置，且在設計上引入計算機局域網絡技術，功能分配采用盡可能下放的原則，這種結構雖然可靠性大大提高，任一間隔故障不會影響其它間隔，但是對于每一間隔來說可靠性就比較低，如果間隔內任一個發生故障，則會影響整個間隔。

1.2　面向對象的分布式系統

即一個單元對一個對象，每一根進線、每一根出線、每臺變壓器、電容器等都可作為對象。這是一種真正的全分布式的變電站綜合自動化系統，它打破了原有二次設備的功能界限，根據變電站綜合自動化的要求重新組合。這種面向對象的分布式系統符合國際電工委員會的技術規范，是今后的發展方向。它具有以下特點：系統可靠性大大提高，局部故障不影響系統運行；模塊間相對獨立，互相影響小；數據共享性好；系統運行效率高；多功能的綜合控制方式，使得設備的運行管理十分簡單，維護量少；抗干擾能力強；可擴展性好；站內二次設備所需電纜大大減少，節約投資。

2、雙網絡與單網絡總線結構

站級管理層與保護監控層之間的數據及命令傳遞，可采用雙網絡或單網絡結構。對110　kV樞紐變電站，采用雙網絡結構便于在數據流量很大時保證能快速傳遞各類信號，并提高其可靠性。采用雙網絡方式時，通常將監控和保護獨立組網，在輸電線路或電氣設備故障保護動作后，可利用保護網快速傳遞錄波數據。由110kV及以下變電站規模較小，數據流量不大，110kV及以下變電站采用單網絡即可很好地滿足數據傳輸的要求。

3、RS485或CAN現場總線網

3.1　RS485　總線

RS2485　總線較早應用于變電站綜合自動化系統，目前仍為許多系統所采用，其缺點主要有：對于較小規模系統，有足夠的傳輸率，實時性有保證，但隨著系統規模的擴大，系統性能迅速降低。抗干擾及安全性較差，一般只適宜于在控制室內部使用，不能用于開關場及開關間隔內，即不適用于分散安裝的分布式系統。從結構網絡上只能有一個主節點，其余均為從節點，各I/O單元橫向通信必須經過站級計算機進行，系統靈活性差。數據通信方式是命令響應式，節點只有在收到主節點的命令后才能響應，一些重要的變位信息得不到及時上送，實時性較差。無檢錯糾錯功能。通信規約由各廠家自定，不同系統設備間難以互聯。

3.2　CAN　總線型網絡

采用短幀傳送，且每幀均有CRC　校驗和其它檢錯措施，抗干擾能力強，只需采用廉價的雙絞線傳輸就可保證誤碼率≤10-11。網絡直接通信距離最遠可達10km，此時傳輸速率為5kbit/s，而當傳輸距離為40m時，傳輸速率可達1Mbit/s。按多主方式工作，網絡上任一節點均可在任意時刻向網絡上其它節點發送信息，而且還可按點對點、一點對多點和全局廣播等方式傳送信息，通信方式靈活。網絡上的節點可以設置成不同的優先級別，并采用非破壞性總線裁決技術，當有兩個節點同時向網絡上傳送信息時，優先級低的節點會自行暫停發送，但優先級高的節點卻不受影響繼續發送，從而大大地節省了總線沖突裁決時間，以保證整個系統的實時性。網絡上某個節點異常時，有自動關閉總線的功能，切斷該節點與總線的聯系，以保證總線上其它操作不受影響。CAN網絡符合ISO11898技術規范，具有良好的開放性和硬件支持環境。

4、后臺操作系統

4.1　WindowsNT操作系統

硬件向上兼容性好，不需要人工進行硬件的優化配置。支持軟件多，可移植性強，易于二次開發和功能擴展。有全方位多功能的系統配置組態功能，包括系統配置、圖形、報表、曲線、事件處理方式等，使系統生成修改極為快捷、靈活、方便；多種報表配置生成及輸出，全部基于Excel　電子報表，便于管理并與其他工具接口；標準的大型數據系統SQL　Server　或Sybase　作為實時及歷史數據庫，系統容量大，保證了數據完整性和一致性，易于維護并能與其它系統無縫連接。界面直觀，通用性強，用戶普遍會使用，減少培訓的工作量。系統運行的穩定性略差，有時由于任務多易發生死機。安全性不高，易受計算機病毒的侵入。基于該操作系統的應用軟件有的具有識別碼，從保密的角度限制了它的使用范圍。

4.2　SCOUN　IX　系統

硬件兼容較為嚴格，　一般的PC　機顯卡在圖形環境下不能兼容，即使兼容，其分辨率也較低，大多≤1024×768。需要對系統進行優化配置，這項工作一般使用人員難以勝任。支持軟件較少，應用系統組態軟件要自行編制。操作系統為英文環境，對國內用戶來說較難掌握。有較長時間的運行經驗及完善改進，穩定性好，安全性高，軍工、金融等行業對可靠性要求較高的網絡普遍采用。

5、變電站自動化系統應能實現的功能

5.1　微機保護

是對站內所有的電氣設備進行保護，　包括線路保護，　變壓器保護，　母線保護，　電容器保護及備自投，　低頻減載等安全自動裝置。各類保護應具有下列功能：

（1）故障記錄；（2）存儲多套定值；　（3）顯示和當地修改定值；（4）與監控系統通信。根據監控系統命令發送故障信息，　動作序列。當前整定值及自診斷信號。接收監控系統選擇或修改定值，　校對時鐘等命令。通信應采用標準規約。

5.2數據采集及處理功能

5.2．1　狀態量采集

狀態量包括：　斷路器狀態，　隔離開關狀態，　變壓器分接頭信號及變電站一次設備告警信號、事故跳閘總信號、預告信號等。目前這些信號大部分采用光電隔離方式輸入系統，　也可通過通信方式獲得。

5.2.2　模擬量采集

常規變電站采集的典型模擬量包括：　各段母線電壓、線路電壓，　電流和有功、無功功率值。饋線電流，電壓和有功、無功功率值。

5．3　控制和操作功能

操作人員可通過后臺機屏幕對斷路器，　隔離開關，　變壓器分接頭，　電容器組投切進行遠方操作。為了防止系統故障時無法操作被控設備，　在系統設計時應保留人工直接跳合閘手段。

5.4　系統的自診斷功能

系統內各插件應具有自診斷功能，　并把數據送往后臺機和遠方調度中心。對裝置本身實時自檢功能，方便維護與維修，　可對其各部分采用查詢標準輸入檢測等方法實時檢查，　能快速發現裝置內部的故障及缺陷，　并給出提示，　指出故障位置。

5.5　人機聯系系統的自診斷功能

系統內各插件應具有自診斷功能，　自診、斷信息也像被采集的數據一樣周期性地送往后臺機和遠方調度中心或操作控制中心與遠方控制中心通信。本功能在常規遠動“四遙”的基礎上增加了遠方修改整定保護定值、故障錄波與測距信號的遠傳等，　其信息量遠大于傳統的遠動系統。還應具有同調度中心對時，　統一時鐘的功能和當地運行維護功能。

參考文獻

第3篇：分布式系統設計原則范文

關鍵詞：CORBA; DII; Java

中圖分類號：TP311文獻標識碼：A 文章編號：1009-3044(2008)06-11010-02

The Design and Implementation of the CORBA Server Interfaces Test Tool

BI Xue-jun,XIAO Qing,HAO Na

(Department of Information Engineering of Academy of Armored Force Engineering,Beijing 100072,China)

Abstract: The paper introduces the design and implementation of the CORBA server interfaces test tool CTester. It is independent of platform, providing a graphic user interface,supporting for script definition and dynamic invocation. It provides an easy way to test distribute system.

Key words: CORBA(Common Object Request Broker Architecture); DII (Dynamic Invocation Interface); Java

1 引言

隨著Internet的廣泛運用，將應用擴展到局域網、廣域網甚至Internet上已成為用戶的普遍需求，為此分布式計算成了新的熱點。在分布式計算環境中，異構性是一個十分明顯的特點。一個典型的分布環境包括有大型主機、UNIX工作站和PC機，各種機器所采用的操作系統和網絡通信協議也是千差萬別，在這樣的異構環境下實現信息和軟件資源的共享將十分困難，而一個健壯的分布計算框架將為分布應用軟件的開發帶來極大的好處。為了實現這一目標，OMG組織于1991年提出了公用對象請求程序結構的技術規范CORBA[1]（Common Object Request Broker Architecture，通用對象請求體系結構）。CORBA規范充分利用了現今軟件技術發展的最新成果，在基于網絡的分布式應用環境下實現應用軟件的集成，使得面向對象的軟件在分布、異構環境下實現可重用、可移植和互操作。

要想編寫一個良好健壯的CORBA應用程序，首先需要進行有效的測試。一般的測試過程是，開發人員編寫完CORBA服務器程序后，首先花費一定的時間開發客戶程序來調用CORBA服務器對象。如果要針對大量的各種輸入數據進行測試，那么客戶端測試程序的開發工作量將會很大。因此需要研制開發CORBA服務器接口測試工具，進行有效的CORBA對象接口測試，驗證CORBA接口實現的正確性。

2 系統設計

該CORBA服務器接口測試工具以下簡稱為CTester，它能夠向CORBA對象調用指定的操作，獲取或設置CORBA對象的屬性，驗證CORBA接口的實現，其參數設置方便，測試結果顯示直觀。支持測試腳本定義，用戶熟悉IDL就可以編寫測試腳本，測試腳本建立簡便，可重復使用。該工具完全采用java編寫，遵從CORBA2.3規范[2]，工作平臺為IONA公司的orbix2000[3]。

2.1 設計原則

Ctester測試工具在開發過程中，遵循以下幾個原則：

1)平臺無關性：測試工具的運行應保證與操作系統無關，因此系統采用JAVA語言實現；

2)使用簡便靈活：采用圖形化GUI界面，使用簡便靈活，顯示結果直觀，操作易于掌握；

3)支持腳本定義：用戶熟悉IDL就可以編寫測試腳本，測試腳本建立簡便，可重復使用；

4)采用動態調用DII：動態方式允許對任意對象進行操作，借助接口庫，動態方式可以在運行時刻查詢各對象所支持的操作，無論是操作的對象、發起調用的參數，還是發起調用的次數等等都可以由客戶程序在運行時刻視當時環境和需要而決定。因此，采用動態方式相對靜態方式而言靈活性大大增強。

2.2 系統結構

整個系統結構按功能劃分為六個模塊，分別是測試控制模塊、腳本定制模塊、腳本解釋模塊、測試驅動模塊、動態調用模塊、結果處理模塊。其中測試控制模塊提供了一個總的控制界面，進行測試過程的控制和管理，測試人員輸入指令，進行任意指定參數的操作或屬性調用。在調用結束后，由測試結果處理模塊處理并顯示返回值及輸入/輸出參數，結果也可以保存在文件中。

腳本定制模塊采用IDL格式定義測試腳本，能夠編輯、管理測試腳本文件。用戶熟悉IDL就可以編寫測試腳本，測試腳本的解釋由腳本解釋模塊進行。通過測試腳本可以向CORBA對象調用指定的操作，也可以獲取或設置CORBA對象的屬性。

在測試執行過程中，測試驅動模塊和動態調用模塊從接口存儲庫載入被測CORBA對象IDL細節。為了保持測試工具的靈活性，采用動態調用方式。系統結構如圖1所示：

3 CTester工具實現的關鍵技術

3.1 動態調用技術DII

CORBA服務器接口測試工具CTester從Client/Server模式看，實際上相當于客戶端，客戶程序對遠端對象的調用，有兩種方式：靜態方式和動態方式。本測試工具需要對任意CORBA服務器的屬性/操作進行調用，因此采用動態調用DII[4]的方式，相對靜態方式而言，該種方式有以下幾個優點：

(1)靈活。動態方式允許對任意對象進行操作，所需要的只是目標對象的對象引用。借助接口庫，動態方式可以在運行時刻查詢對象所支持的屬性/操作信息，大大提高了程序的靈活性。

(2)客戶程序的可移植性增強。由于DII與客戶之間的接口是標準的，因此由動態方式實現的代碼具有良好的可移植性。

(3)可執行程序的“體積”小。與靜態方式不同，DII不需要為每個接口生成碼根和框架，無論程序中使用多少接口，所需要的只是一套支持DII的接口庫，這樣可執行程序的“體積”會相對較小。

當然，與靜態方式相比，動態方式有以下的缺點：

(1)使用復雜。使用靜態方式時，對目標對象的操作都施加在一個本地的對象上，相應對象支持的所有操作及格式都已經預先定義在這個對象中，因而使用方便。在動態方式下，程序員需要自己動手，“臨時”構建一個請求并發送，同時程序還需要查詢接口庫以獲得屬性/操作必要描述信息，這些過程都較靜態方式復雜。

(2)速度緩慢。由于靜態方式下類型信息都是確定的，因此速度較快；而動態方式實現時，類型信息都是動態獲知，速度不可避免要慢一些。此外，程序要花去大量時間來查詢接口庫，尤其當被查詢的接口定義存放在遠端時，這些查詢還會引發遠端調用，致使動態方式的速度變得更慢。

鑒于上述動態調用速度緩慢的缺點，為避免程序每次調用都去查詢接口庫來獲得屬性/操作的描述信息，我們采用預先將接口庫中所有數據類型的接口定義對象轉化為本地用java實現的類對象，這樣程序就不必花費大量的時間來查詢接口庫，而只需調用所需類的屬性或方法即可，大大提高了調用執行的效率。

動態調用的過程簡要歸納如下：

(1)獲得接口名，將目標對象接口信息注冊到接口庫中；

(2)從接口庫的對象中，找到所要調用的操作（或方法）的描述；

(3)建立調用參數表，并逐一填入參數；

(4)創建請求，請求中應包括目標對象的引用、方法名、參數表和返回值；

(5)調用請求，并作結果處理。

3.2 采用面向對象的系統實現系統采用面向對象的思想，將接口庫中各種數據類型對象一一轉化為用java類實現的對象，對CORBA服務器屬性/操作的調用變成了對相應java類的屬性方法調用，提高了接口庫查詢效率，使得程序結構更加合理，易于維護。啟動CTester工具后首先要執行“Load-ifr”命令，將接口庫中所有IDL文件詳細描述信息裝入CorbaRepository類[5]，其中也包括要測試的CORBA服務器IDL描述文件信息，然后再調用“attribute”或“operation”命令對CORBA服務器中的屬性、參數進行設置/獲取，對CORBA服務器中的操作進行調用，獲得inout/out參數結果和返回值，驗證結果返回值是否正確。

4 總結

本課題在對CORBA服務器接口測試技術經過大量的研究后，開發了相應的測試工具來驗證CORBA接口的實現，該工具可以為分布式系統的開發提供測試手段。

參考文獻：

[1] 汪蕓．CORBA技術及其應用[M]．江蘇：東南大學出版社，1999.1-12.

[2] 朱其亮,鄭斌．CORBA 原理及應用[M]．北京：北京郵電大學出版社，2001.15-37.

[3] Orbix 2000 Programmer’s Guide Java Edition[EB/OL]．．2004-09-16.

第4篇：分布式系統設計原則范文

關鍵詞:集散控制系統;機柜集成;管理信息系統;專家數據庫

中圖分類號:TP291文獻標識碼:A

文章編號:1009-2374 (2010)22-0026-03

0引言

20世紀70年代后,信息技術的發展引起了多個技術領域的深刻變革,這場變革對傳統自動化行業的影響也是巨大的,過程控制技術在這場變革中有了質的飛躍。經過幾十年的發展,當前過程控制技術已有了巨大的進步。

雖然DCS技術有了巨大的發展,國內外很多企業都已掌握了成熟的技術,但是應用于DCS的機柜集成信息技術幾乎依然處于空白狀態。目前許多企業已經認識到利用管理信息系統對DCS機柜集成流程的改造,能夠使傳統DCS企業適應激烈競爭環境并取得主導地位。但是這些企業對于機柜集成的管理研究還處在起步階段,在實現項目管理信息化的過程中,還存在許多認識和方法上的誤區。

1DCS機柜特點分析

1.1DCS系統簡介

DCS是一類分散控制、集中管理的儀表計算機控制系統。它具有連接方便、采用軟連接方法使控制策略更改容易、顯示方式靈活、顯示內容多樣和數據存儲量大等優點。DCS由被控對象、用于生產過程的參數檢測與變送儀表、控制站、執行機構和報警部件等組成。它的各組成部分是各自為政的自治和協調系統。自治系統指這些系統能完成自己的功能和獨立工作,協調系統指這些組成部分用通信網絡和數據庫相互連接,信息數據相互交換,既有分工又相互制約,在系統協調下工作。

正是因為DCS系統的復雜程度高而導致了用于系統載體的機柜具有特殊性和多樣性。

1.2控制站機柜多樣性描述

現場控制站是一套可獨立運行的計算機檢測控制系統,由機柜、電源、I/O模塊和控制處理器等組成。DCS系統的硬件基本上都安裝在機柜中,不同廠商的DCS控制系統在硬件結構上相差很大,即使是同一廠商的產品也會不斷升級換代,而且根據用戶的需求,針對不同的用戶在硬件配置上也不盡相同,這就需要不同的控制柜。

現場控制站的機柜內部均裝有二次結構,以供安裝I/O模塊、電源、繼電器及各種接線端子。控制站的機柜按照功能劃分可以分為主機柜、I/O柜、繼電器柜和端子柜等。不同類型的機柜都有各自的特點。主機柜內部的控制設備需要提供完善的電磁屏蔽,活動部分之間要保證有良好的電氣連接;端子柜中交直流和信號線都需要隔離走線;本安機柜和非本安機柜的匯線槽和接線端子顏色需要區分開來。這些不同的技術規范就要求機柜內部結構多樣化。

由于硬件配置原因,機柜內部結構很難做到標準化,這樣造成了機柜多樣性,使DCS項目機柜集成變得非常復雜和繁瑣。

2機柜集成現狀

目前機柜集成的時間節點是從銷售部把拿到的訂單移交給工程部開始,到制造部把集成后經過測試的機柜發運給用戶結束。中間經過的主要環節有工程軟硬件配置、材料清單確定、零部件采購和機柜裝配與接線等。下面把以上提到的環節作展開說明:

2.1工程軟硬件配置

這個過程一般由項目經理負責。其根據系統項目要實現的功能和信號來配置系統軟硬件,但對于機柜和其他結構件不作選型,也就是說用于系統項目的控制類標準件比較容易確定,但是其他輔料等非標件難以定型,項目經理需要就這個問題不斷和工藝工程師去討論。如果有一個專家數據庫系統,項目經理可以在軟硬件配置階段直接完成整個系統設計。

2.2材料清單確定

這個環節原來應由項目工程師完成,和上述工程軟硬件配置以及下面要談到的機柜二次結構設計一樣,如果在軟硬件配置階段,有一個專家數據庫,材料清單就可以產生。目前這個工作通常由工藝工程師完成,工藝工程師按照項目經理提供的典型圖紙和自己的經驗來完成詳細材料的配置。

2.3零部件采購

目前機柜集成除了裝配圖紙生成和材料清單不能在很短的時間內完成之外,還有一個很大的問題就是缺料。由于DCS系統的特點,DCS系統所用到的機柜內部安裝材料,包括控制器、I/O模塊、電纜,風扇,空氣開關和接線端子等,都具有小批量多品種的特征,這給采購帶來了巨大的挑戰。解決這個問題需要有一個管理系統,可以對交貨期長的零件、項目之間材料調用、材料需求預測和庫存看板進行統一管理。

2.4機柜裝配與接線

在這里出現的問題主要是生產調度。在生產現場的每一個項目都不相同,生產調度無法做到一個靜態調度,由于缺料、圖紙更改和生產過程中的突發事件等各種原因,很難對生產資源、機柜集成次序、機柜集成過程和質量進行管理,要實現精益生產必須要有一個統一的管理系統。

3管理系統設計原則

對于上面描述的DCS機柜特點和目前DCS機柜集成中出現的問題,可以設計一套管理信息系統來解決。下面詳細說明五條設計原則:

3.1系統性

機柜集成的管理是一個統一的整體,從母公司到子公司需要全局考慮,從工程部門到制造部門需要協同合作,管理信息系統在設計過程中必須從系統的整體角度出發進行設計。從整體角度考慮各個子系統的相互協調相互平衡的關系,可以使每個子系統的所有信息進行共享,設計的系統性必須按照機柜集成的電氣規范、安全標準和各種防護等級。

3.2可變性

DCS系統項目本身是一個不斷完善的系統,機柜集成同樣如此。管理信息系統是個龐大的系統,它需要保持較長的生命周期,所以要求它具有很強的環境適應性,要具有較好的開放性和結構可變性。在管理系統設計中,按照機柜設計、生產流程、材料采購和質量管理進行模塊化處理,并且要提高各模塊的獨立性,使各個模塊之間的相互依存度降到最低。這樣可以按照每個模塊修改管理系統,以后可以單獨增加功能。

3.3可靠性

DCS項目從和用戶開工程會開始,留給集成供應商的時間并不很充裕,所以要求在做系統項目的過程中不能出差錯。機柜集成管理系統也必須做到這一點,一定要有很強的抵御外界干擾的能力和失效后恢復正常使用的能力。

3.4高效性

DCS項目工期很短,機柜集成處于整個項目的前期,如果機柜集成效率低下,勢必造成后期的系統組態和調試相當緊張,有可能造成延期發運。所以管理信息系統在規定的時間內處理事務的能力較強,能夠迅速地對處理請求做出響應。

3.5經濟性

在金融危機之下,每個企業都在提高工作效率,同時也在降低生產和管理成本。機柜集成管理系統要在滿足需求的前提下,盡可能減少系統開銷。一方面在硬件投入上做到簡潔且符合系統要求;另一方面設計不要過于復雜,各個模塊在保證功能的情況下減少開發費用。

4管理系統框架

系統設計原則確定下來以后,然后需要考慮管理系統的框架設計,這是管理信息系統開發過程中一個非常重要的階段。

4.1總體布局

一般信息系統總體布局分為集中式和分布式兩種,DCS系統機柜的管理系統設計必須按照分布式進行。分布式系統可以運用局域網、廣域網、局域網和廣域網混合形式及互聯網、內聯網、外聯網及其混合形式,利用這些計算機網絡把分布在不同地點的計算機硬件、軟件和數據等資源聯系在一起進行聯機處理。

4.2專家數據庫

由于機柜具有零件眾多、裝配工藝復雜和設計多樣等特點,要成功開發一個管理信息系統必須要配備專家數據庫系統。專家系統的數據庫是經特別設計的計算機程序,用來復制自動化工程領域機柜集成專家的推理和決策過程。專家系統按照實際項目要求,可以對機柜集成知識庫中的知識和數據庫中的數據加以智能性分析、判斷,得出結論以供設計人員參考。根據這個專家系統可以開發各種工具,如圖紙生成器、材料清單生成器和工程更改通知單等一系列工具。有了這樣一個面向應用者的專家系統數據庫,相關機柜集成工程師可以很容易地利用它報價、選型和計算機模擬裝配。

4.3硬件配置設計

由于機柜集成管理系統按照分布式設計,通過網絡實現,所以在硬件上有兩方面需求,即計算機系統配置和網絡平臺設計。關于計算機的選型要考慮系統未來的升級可能和第三方軟件的支持,使管理系統具有延續性。另外硬件配置要考慮數據處理能力、存儲功能和通信功能。由于管理系統是一個全球性的系統,每個子系統都要利用這個管理系統,所以網絡平臺要考慮實用性、先進性和開放性。

4.4軟件設計平臺

信息系統軟件平臺是指支持系統開發和運行的軟件平臺。開發一個全球性的龐大的信息系統要保證開發維護簡單易行,而且開發的系統運行要高效可靠。機柜集成對于一個跨國公司來說,要做到標準化和統一性。軟件平臺必須符合開放式的發展方向,要與其他系統互聯及互操作性。一個跨國公司花了大量的人力物力,要保證這個管理系統建設成功、生存和發展。這個管理系統所設置的軟件平臺必須支持必要的軟件開發工具,比如數據庫開發工具、界面開發工具和應用工具等。另外這個軟件平臺要有對新技術的支持能力。DCS技術還在不斷發展之中,機柜集成也隨著DCS的發展也在不斷變化之中,管理信息系統也需要跟著改變。只有支持新技術能力的平臺才能適應系統今后發展的需要。

5結語

由于DCS機柜集成的多樣化和非標準化等特點,傳統機柜集成孤島模式已不適應當前快速響應的市場要求,因此應用管理信息系統已成了機柜集成發展的必然趨勢。管理信息系統把項目運行過程中的信息技術、生產技術和企業的各種生產與經營活動有機高效地結合起來,能夠保證機柜集成企業有效地運轉,去創造最大的經濟和社會效益。

參考文獻

[1] 俞金壽.信息科學與工程[M].北京:科學出版社,2008.

[2] 方康玲.過程控制與集散系統[M].北京:電子工業出版社,2009.

[3] 何衍慶,黃海燕,黎冰.集散控制系統原理及應用[M].北京:化學工業出版社,2009.

[4] 黃桂梅.計算機控制技術與系統[M].北京:中國電力出版社,2008.

[5] 羅煥佐,宋國寧,王曉峰.流程企業智能計劃調度技術[M].遼寧:東北大學出版社,2004.

[6] 陳京民.管理信息系統[M].北京:清華大學出版社,北京交通大學出版社,2006.

第5篇：分布式系統設計原則范文

關鍵詞：變電站，綜合自動化，功能，智能單元

1． 引言

近年來，隨著電網運行水平的提高，各級調度中心要求更多的信息，以便及時掌握電網及變電站的運行情況，提高變電站的可控性，進而要求更多地采用遠方集中控制，操作，反事故措施等，即采用無人值班的管理模式，以提高勞動生產率，減少人為誤操作的可能，提高運行的可靠性。另一方面，當代計算機技術，通訊技術等先進技術手段的應用，已改變了傳統二次設備的模式，為簡化系統，信息共享，減少電纜，減少占地面積，降低造價等方面已改變了變電站運行的面貌。基于上述原因，變電站自動化由“熱門話題”已轉向了實用化階段，電力行業各有關部門把變電站自動化做為一項新技術革新手段應用于電力系統運行中來，各大專業廠家亦把變電站自動化系統的開發做為重點開發項目，不斷地完善和改進相應地推出各具特色的變電站綜合自動化系統，以滿足電力系統中的要求。

國外從80年代初開始進行研究開發，到目前為止，各大電力設備公司都陸續地推出系列化的產品。如ABB，SIEMENS，HARRIS等公司，90年代以來，世界各國新建變電站大部分采用了全數字化的二次設備；相應地采用了變電站自動化技術；我國開展變電站綜合自動化的研究及開發相比世界發達國家較晚，但隨著數字化保護設備的成熟及廣泛應用，調度自動化系統的成熟應用，變電站自動化系統已被電力系統用戶接受使用，但在電力部門使用過程中大致有兩方面的原則：一是中低壓變電站采用自動化系統，以便更好地實施無人值班，達到減人增效的目的；二是對高壓變電站（220kV及以上）的建設和設計來說，是要求用先進的控制方式，解決各專業在技術上分散、自成系統，重復投資，甚至影響運行可靠性。并且在實際的工程中尚存在以下主要問題：

(1)功能重復，表現在計量，遠動和當地監測系統所用的變送器各自設置，加大了CT，PT負載，投資增加，并且還造成數據測量的不一致性；遠動裝置和微機監測系統一個受制于調度所，一個是服務于當地監測，沒有做到資源共享，增加了投資且使現場造成復雜性，影響系統的可靠性；

(2) 缺乏系統化設計 而是以一種”拼湊”功能的方式構成系統，致使 整個系統的性能指標不高，部分功能及系統指標無法實現。

（3）對變電站綜合自動化系統的工程設計缺乏規范性的要求，尤其是系統的各部分接口的通信規約，如涉及到不同廠家的產品，則問題更多，從而導致各系統的聯調時間長，對將來的維護及運行都帶來了極大的不便，進而影響了變電站自動化系統的投入率。

2． 變電站綜合自動化系統應能實現的功能

2．1 微機保護：是對站內所有的電氣設備進行保護，包括線路保護，變壓器保護，母線保護，電容器保護及備自投，低頻減載等安全自動裝置。各類保護應具有下列功能：

1）．故障記錄

2）．存儲多套定值

3）．顯示和當地修改定值

4）．與監控系統通信。根據監控系統命令發送故障信息，動作序列。當前整定值及自診斷信號。接收監控系統選擇或修改定值，校對時鐘等命令。通信應采用標準規約。

2．2　數據采集

包括狀態數據，模擬數據和脈沖數據

1）．狀態量采集

狀態量包括：斷路器狀態，隔離開關狀態，變壓器分接頭信號及變電站一次設備告警信號等。目前這些信號大部分采用光電隔離方式輸入系統，也可通過通信方式獲得。

保護動作信號則采用串行口（RS-232或RS485）或計算機局域網通過通信方式獲得。

2）．模擬量采集

常規變電站采集的典型模擬量包括：各段母線電壓，線路電壓，電流和功率值。饋線電流，電壓和功率值，頻率，相位等。此外還有變壓器油溫，變電站室溫等非電量的采集。

模擬量采集精度應能滿足SCADA系統的需要。

3）．脈沖量

脈沖量主要是脈沖電度表的輸出脈沖，也采用光電隔離方式與系統連接，內部用計數器統計脈沖個數，實現電能測量。

2．3　事件記錄和故障錄波測距

事件記錄應包含保護動作序列記錄，開關跳合記錄。其SOE分辨率一般在1~10ms之間，以滿足不同電壓等級對SOE的要求。

變電站故障錄波可根據需要采用兩種方式實現，一是集中式配置專用故障錄波器，并能與監控系統通信。另一種是分散型，即由微機保護裝置兼作記錄及測距計算，再將數字化的波型及測距結果送監控系統由監控系統存儲和分析。

2．4　控制和操作閉鎖

操作人員可通過CRT屏幕對斷路器，隔離開關，變壓器分接頭，電容器組投切進行遠方操作。為了防止系統故障時無法操作被控設備，在系統設計時應保留人工直接跳合閘手段。操作閉鎖應具有以下內容：

1）．電腦五防及閉鎖系統

2）．根據實時狀態信息，自動實現斷路器，刀閘的操作閉鎖功能。

3）．操作出口應具有同時操作閉鎖功能

4）．操作出口應具有跳合閉鎖功能

2．5　同期檢測和同期合閘

該功能可以分為手動和自動兩種方式實現。可選擇獨立的同期設備實現，也可以由微機保護軟件模塊實現。

2．6　電壓和無功的就地控制

無功和電壓控制一般采用調整變壓器分接頭，投切電容器組，電抗器組，同步調相機等方式實現。操作方式可手動可自動，人工操作可就地控制或遠方控制。

無功控制可由專門的無功控制設備實現，也可由監控系統根據保護裝置測量的電壓，無功和變壓器抽頭信號通過專用軟件實現。

2．7　數據處理和記錄

歷史數據的形成和存儲是數據處理的主要內容，它包括上一級調度中心，變電管理和保護專業要求的數據，主要有：

1）．斷路器動作次數

2）．斷路器切除故障時截斷容量和跳閘操作次數的累計數

3）．輸電線路的有功、無功，變壓器的有功、無功、母線電壓定時記錄

的最大，最小值及其時間。

4）．獨立負荷有功、無功，每天的峰谷值及其時間

5）．控制操作及修改整定值的記錄

根據需要，該功能可在變電站當地全部實現，也可在遠動操作中心或調度中心實現。

2．8 人機聯系

2．9　系統的自診斷功能：系統內各插件應具有自診斷功能，自診斷信息也象被采集的數據一樣周期性地送往后臺機和遠方調度中心或操作控制中心。

2．10與遠方控制中心的通信

本功能在常規遠動‘四遙’的基礎上增加了遠方修改整定保護定值、故障錄波與測距信號的遠傳等，其信息量遠大于傳統的遠動系統。

根據現場的要求，系統應具有通信通道的備用及切換功能，保證通信的可靠性，同時應具備同多個調度中心不同方式的通信接口，且各通信口及MODEM應相互獨立。保護和故障錄波信息可采用獨立的通信與調度中心連接，通信規約應適應調度中心的要求，符合國標及IEC標準。

變電站綜合自動化系統應具有同調度中心對時，統一時鐘的功能，還應具有當地運行維護功能。

2．11 防火、保安系統。從設計原則而言，無人值班變電站應具有防火、保安措施。

轉貼于 3．變電站綜合自動化的結構及模式

3．1 目前從國內、外變電站綜合自動化的開展情況而言，大致存在以下幾種結構：

1）．分布式系統結構

按變電站被監控對象或系統功能分布的多臺計算機單功能設備，將它們連接到能共享資源的網絡上實現分布式處理。這里所談的‘分布’是按變電站資源物理上的分布（未強調地理分布），強調的是從計算機的角度來研究分布問題的。這是一種較為理想的結構，要做到完全分布式結構，在可擴展性、通用性及開放性方面都具有較強的優勢，然而在實際的工程應用及技術實現上就會遇到許多目前難以解決的問題，如在分散安裝布置時，惡劣運行環境、抗電磁干擾、信息傳輸途徑及可靠性保證上存在的問題等等，就目前技術而言還不夠十分成熟，一味地追求完全分布式結構，忽略工程實用性是不必要的。

2）．集中式系統結構

系統的硬件裝置、數據處理均集中配置，采用由前置機和后臺機構成的集控式結構，由前置機完成數據輸入輸出、保護、控制及監測等功能，后臺機完成數據處理、顯示、打印及遠方通訊等功能。目前國內許多的廠家尚屬于這種結構方式，這種結構有以下不足：前置管理機任務繁重、引線多，是一個信息‘瓶頸’，降低了整個系統的可靠性，即在前置機故障情況下，將失去當地及遠方的所有信息及功能，另外仍不能從工程設計角度上節約開支，仍需鋪設電纜，并且擴展一些自動化需求的功能較難。在此值得一提的是這種結構形成的原由，變電站二次產品早期開發過程是按保護、測量、控制和通信部分分類、獨立開發，沒有從整個系統設計的指導思想下進行，隨著技術的進步及電力系統自動化的要求，在進行變電站自動化工程的設計時，大多采用的是按功能‘拼湊’的方式開展，從而導致系統的性能指標下降以及出現許多無法解決的工程問題。

3）．分層分布式結構

按變電站的控制層次和對象設置全站控制級（站級）和就地單元控制級（段級）的二層式分布控制系統結構。

站級系統大致包括站控系統（SCS）、站監視系統（SMS）、站工程師工作臺（EWS）及同調度中心的通信系統（RTU）：

站控系統（SCS）：應具有快速的信息響應能力及相應的信息處理分析功能，完成站內的運行管理及控制（包括就地及遠方控制管理兩種方式），例如事件記錄、開關控制及SCADA的數據收集功能。

站監視系統（SMS）：應對站內所有運行設備進行監測，為站控系統提供運行狀態及異常信息，即提供全面的運行信息功能，如擾動記錄、站內設備運行狀態、二次設備投入/退出狀態及設備的額定參數等。

站工程師工作臺（EWS）：可對站內設備進行狀態檢查、參數整定、調試檢驗等功能，也可以用便攜機進行就地及遠端的維護工作。

上面是按大致功能基本分塊，硬件可根據功能及信息特征在一臺站控計算機中實現，也可以兩臺雙備用，也可以按功能分別布置，但應能夠共享數據信息，具有多任務時實處理功能。

段級在橫向按站內一次設備（變壓器或線路等）面向對象的分布式配置，在功能分配上，本著盡量下放的原則，即凡是可以在本間隔就地完成的功能決不依賴通訊網，特殊功能例外，如分散式錄波及小電流接地選線等功能的實現。

這種結構相比集中式處理的系統具有以下明顯的優點：

（1）可靠性提高，任一部分設備故障只影響局部，即將‘危險’分散，當站級系統或網絡故障，只影響到監控部分，而最重要的保護、控制功能在段級仍可繼續運行；段級的任一智能單元損壞不應導致全站的通信中斷，比如長期霸占全站的通信網絡。

（2） 可擴展性和開放性較高，利于工程的設計及應用。

（3） 站內二次設備所需的電纜大大減少，節約投資也簡化了調試維護。

3．2 基本的模式

1）．基本配置：

（1） 集中處理集中布置：將集控式屏、臺都集中布置在主控制室。

（2） 分布處理集中布置：將分布式單功能設備集中組屏仍集中布置在主控制室。

（3） 分布處理分散布置：將分布式單功能設備布置在一次設備的機柜內或采用就地就近組屏分散設置的方式。

2）．基本模式：

（1） 對于新建變電站的自動化系統的設計方式：

A．對于容量較大、設備進出線回路數較多、供電地位重要且投資較好的變電站，可采用分層分布式結構的雙機備用系統，輔之相應的保護、測量、控制及監測功能，并完成遠方RTU的功能。

B．對于容量較小，主接線簡單，供電連續性要求不高的變電站，宜取消常規的配置及前置機，采用單機系統，完成保護、測量、控制等功能的管理，并完成遠方RTU的功能。

（2） 對于擴建及改造現有的按常規二次系統設計的自動化系統設計方式：

A．改造項目可采用新配置的具有三遙（或四遙）功能的RTU，完成對老站保護動作信息、設備運行狀態及部分功能的測量，并對原有的常規二次設備進行必要的改造或RTU增加數據采集板，使之能與增設的自動化設備構成整體。

B．當擴建項目的范圍較大，用戶對自動化的要求較高，投資又允許時，通常采用自動化系統方案。

4． 幾個問題的認識及探討

4．1　變電站自動化的基本概念

變電站自動化是指應用自動控制技術、信息處理和傳輸技術，通過計算機硬軟件系統或自動裝置代替人工進行各種運行作業，提高變電站運行、管理水平的一種自動化系統。變電站自動化的范疇包括綜合自動化技術；變電站綜合自動化是指將二次設備（包括控制、保護、測量、信號、自動裝置和遠動裝置）利用微機技術經過功能的重新組合和優化設計，對變電站執行自動監視、測量、控制和協調的一種綜合性的自動化系統，它是自動化和計算機、通信技術在變電站領域的綜合應用。其具有以下特征：

1）．功能綜合化：是按變電站自動化系統的運行要求，將二次系統的功能綜合考慮，在整個的系統設計方案指導下，進行優化組合設計，以達到協調一致的繼電保護及監控系統。‘綜合’（INTEGRATED）并非指將變電站所要求的功能以‘拼湊’的方式組合，而是指在滿足基本要求的基礎上，達到整個系統性能指標的最優化。表現在：

（1） 簡化變電站二次設備的硬件配置，盡量避免重復設計。如遠動裝置和微機監測系統功能的重復設置，沒有達到信息共享。

（2） 簡化變電站各二次設備之間的互聯線，節省控制電纜，減少PT、CT的負載。力爭克服以前計量、遠動和當地監測系統所用的變送器各自設置，不僅增加投資而且還造成數據測量的不一致性。

（3） 保護模塊相對獨立，網絡及監測系統的故障不應影響保護功能的正常工作；對于110kV及以上電壓等級變電站，由于其重要程度，應考慮保護、測量系統分開設置；而對于110kV以下低壓變電站，就目前的技術應用水平及工程應用角度而言，可以考慮將保護與測控功能合為一體的智能單元，這樣不但利于運行管理及工程組合，而且降低投資成本。

（4） 減少安裝施工和維護的工作量，減少總占地面積，降低總造價或運行費用。

（5） 提高運行的可靠性和經濟性，保證電能質量。

（6） 有利于全系統的安全、穩定控制。

2）．系統構成的數字化及模塊化：保護、控制、測量裝置的數字化（即采用微機實現，并具有數字化通信能力），利于把各功能模塊通過通信網絡連接起來，便于接口功能模塊的擴充及信息的共享。另外方便模塊的組態，適應工程的集中式、分布分散式和分布式結構集中式組屏等方式。

3）．操作監視屏幕化：當變電站有人值班時，人機聯系在當地監控系統的后臺機（或主機）上進行，當變電站無人值班時，人機聯系功能在遠方的調度中心或操作控制中心的主機或工作站上進行，不管那種方式，操作維護人員面對的都是CRT屏幕，操作的工具都是鍵盤或鼠標。

4）．運行管理智能化：體現在無人值班、人機對話及操作的屏幕化、制表、打印、越限監視和系統信息管理、建立實時數據庫和歷史數據庫、開關操作及防誤操作閉鎖等方面，能夠減輕工作人員的勞動及人無法做到的工作。

4．2 變電站綜合自動化站內通信網絡的建立

變電站內傳送或交換的基本信息有：測量及狀態信息；操作信息；參數信息。根據信息傳送的性能要求，大致可分兩類考慮，一類要求實時響應較高的信息，如事故的檢出、告警、事件順序記錄和用于保護動作的信息，要求傳送速度較高；另一類是對時間響應要求不高的信息，如用于錄波、記錄及故障分析的信息，可允許較長的傳送時間。對于不同的數據亦有不同的安全性要求，站內通信網聯系站內各個智能單元、后臺監控及遠方通信裝置，是整個系統的關鍵，根據實際系統結構及工程實際需要，大致按以下原則考慮：

1）．電力生產的連續性和重要性，通信網的可靠性應放在第一位．一方面應具有較強的抗干擾能力，以滿足溫度、濕度和電磁干擾等環境要求，另一方面應考慮備用措施。

2）．站內通信網應根據通信負荷的特點合理分配，保證不出現‘瓶頸’現象，通訊負荷不過載，對于大型變電站考慮100~256個負載節點，一般中小型變電站考慮不超過60~100個負載節點。通訊距離設計考慮不超過1kM.。

3）．站內通信網應滿足組合靈活、可擴展性好、具有較好的開放性以及調試維修方便的要求。宜采用總線形網絡。

4）．通信媒介的選用原則是盡量采用光纖，考慮到工程的經濟性，仍可采用電纜作為主要的通信媒介，但電纜接口一般設有隔離變壓器，以抑制共模干擾．

5）．站內通信網的協議及規約應盡量符合國家及國際標準．

6）．站內通信網的站級通信網由于處于較佳的運行環境，其信息流較大（分布式集中布置），故可采用高速網；段級通信網根據實際工程需要，并且可能處于運行環境比較惡劣（分布式分散布置），因實際的信息量不是很大，可考慮慢速網（如現場總線或485通信方式）的環境。

4．3 實際工程設計的考慮

為了使實際工程工作可靠，維護方便，擴展靈活，易于用戶操作和管理，在系統不同的層次，需解決不同的問題。

1）．前置智能單元

前置智能單元是系統的基層，執行系統最基本的功能，如保護、測量、控制等。我們希望這些基層模塊盡量不受網絡狀態的影響，特別是繼電保護裝置，要求在無網絡的狀態下能完成保護的基本功能，因此在設計基層裝置時，盡量采用自成一體的辦法。

為了提高基層功能模塊的質量，盡量采用通用化的模塊，因此硬件平臺的模塊化設計，在基層尤為重要。本著這種思想設計出有限品種的模塊，拼裝成不同的功能裝置，這對模塊設計成本的降低、生產的組織等均具有好處。

在實際應用中，為了減少基層模塊軟件對工程的依賴性（即工程有關部分的軟件），一種辦法將與工程有關的軟件改成系統配置文件存于可擦寫的存儲器內，另一種辦法是將與工程有關的（例如通信規約）軟件用一個獨立的模塊來實現。

2）．網絡通信層

為了保證網絡層的完好，應該注意對網絡層的監視，這可以從后臺和前置兩個層次來實現，在硬件條件比較好的地方，可以采取兩個獨立通訊網絡工作，或同時工作，或者互為備用。

3）．后臺監控

第6篇：分布式系統設計原則范文

關鍵詞:燃料管理；J2EE 架構；信息系統

一、前言

以燃煤為主的火電發電企業，燃料（主要指煤炭）作為其生產經營主要原材料，其具有消耗量大、占用資金量大（約占70％－80％）和燃料的各個特性指標必須滿足鍋爐的設計需要等特點；燃料的質量和價格、運輸方式對電廠的經濟性影響很大，因此，火電廠的燃料管理是無疑是降低成本、提高效益、抗御市場風險的有效方式，是提高企業管理水平，提高燃料質量，降低燃料成本的重要環節，在生產過程中有著舉足輕重的地位。

在“廠網分開、競價上網”為主要內容的電力體制改革后，原來計劃經濟條件下以發電車間形式存在的經營管理模式徹底改變，電廠成為獨立經營的市場經濟主體。在市場經濟規律下運行的發電企業，本著對燃料少投入、多產出的基本原則，在保證機組安全運行的基礎上，運用現代的經濟管理手段，通過煤質分析、成本核算、煤耗分析、經濟活動分析對燃料的供應、耗用和存儲進行全面管理，降低發電成本，使企業獲得良好的經濟效益。

二、燃料管理系統的設計目標

火力發電廠燃料管理是一項復雜的系統工程，涉及燃料訂貨、采購、接卸、驗收化驗及車輛管理、費用結算、配煤燃燒、煤場管理、統計核算等一系列工作。建立從供應、存儲到消耗，貫穿燃料使用過程的一體化燃料管理服務平臺是系統設計的基本思想。本系統建立的設計目標有以下幾個：

（一）降低生產經營成本

由于發電企業生產的連續性，燃料在生產經營中占用資金比重大的特點，通過對燃料庫存的動態管理，在滿足生產經營需要的前提下，保持合適的庫存量，降低整體的庫存成本；財務結算子系統通過加快資金周轉速度和降低資金占用的方法，保證利用同樣的資金使企業獲取更高的經濟效益。

（二）優化資源分配

通過對燃料的供應、存儲和消耗的有效監管，可以合理的利用資源，減少資金、人力和物力的占用，降低燃料的采購成本、儲存成本、經濟使用的效能成本，使其能量能夠被高效利用，保證鍋爐安全穩定燃燒，滿足鍋爐變負荷的需要等。

(三)及時交流信息

充分利用電廠的網絡平臺，快速準確地收集電廠的燃料信息；提供與外部有關系統連接的數據接口，使燃料管理系統融入整個電廠的信息系統；更好的為電廠相關人員提供信息服務；為生產經營提供及時準確的信息服務，為領導決策提供可靠的依據。

二、基于J2EE的燃料信息系統的總體設計

（一）系統的體系結構

該系統是構筑于J2EE平臺上的企業級分布式系統，采用三層J2EE架構設計模式，其體系結構圖如圖一所示。

在客戶表現層利用OCX、DLL等技術實現客戶端的應用模塊，利用SOAP調用遠程服務；在業務邏輯層采用JBOSS作為應用服務運行的中間件環境，使用WebService方式向外提供數據支持服務，同時駐留在中間件服務器上的高性能的EJB組件承擔著全部業務邏輯和數據訪問任務；數據庫管理系統選用Oracle 9i，數據庫連接采用通過JDBC從數據庫連接緩沖池中獲得；系統還提供了與外部遺留系統聯系的接口。

（二）系統主要總控模塊簡介

1 計劃合同模塊：

該模塊是為了及時準確的保證發電企業所需的符合鍋爐燃燒特性的燃料。根據發電計劃和發電標煤消耗率制定出燃料的采購計劃，根據對燃料供應商的評價選擇結果，制定采購合同，簽訂采購單，安排供應商交貨進度等功能，有效管理整個企業的采購業務。用來控制和提高企業的經營活動效率，降低采購成本，節約采購資金。

2 調度管理模塊：

該模塊主要根據燃料合同、電廠燃料的供應、庫存和耗用情況和燃料礦點供應情況進行調整運輸計劃，實現調配、接車和卸車管理；根據發電生產情況和煤場存煤煤質情況，對入爐煤進行調配、調度管理。對汽車衡、軌道衡和皮帶稱的過衡管理，將衡器和皮帶的計量數據自動轉換至管理系統中；并對礦點進行催交、催運管理，保證電廠的燃料供應充足，能夠穩定生產。

3 庫存管理模塊

該模塊主要是對燃料的耗用情況、現存燃料的定期與不定期的盤點情況進行管理和維護，根據燃料的入廠情況，使管理人員對現存燃料的盈虧情況進行查詢和管理，有利于燃料的調運和統計核算。

4 統計核算模塊

該模塊根據燃料的供應、耗用和庫存情況，以及入廠煤、入爐煤的化驗結果等信息進行匯總統計，提供供貨率及盈虧情況，為燃料計劃管理提供信息；根據來煤量、化驗結果、礦點情況等數據，以及合同和價格指標進行核算，對煤量、發熱量盈虧等情況進行索賠，并按一定的結算方式辦理結算手續；對統計核算的結果，用圖形的方式展示，為燃料的成本核算和分析提供依據。

5 煤質管理模塊

該模塊主要實現對某段時間內同一礦點一定數量的入廠煤進行一個批次的采樣、制樣，或對入爐煤根據規定定期進行采樣、制樣，然后由化驗員對煤質進行化驗，實現對入廠煤、入爐煤的采樣管理和煤質化驗管理，為分析燃料變化原因提供依據以及對燃料的核算、分析以及計劃調整提供支持。

結束語

燃料管理是發電企業提高效益的重要環節。本文提出的基于J2EE架構的設計方案，不僅加強了燃料的信息化管理，更重要的是加強了對燃料的購、存、耗的有效監管，使管理人員能夠隨時了解燃料的供存情況，為決策人員的決策提供有效的支持和幫助。

參考文獻：

[1] Deepak Alur. J2EE 核心模式[M]. 劉天北, 譯. 北京: 機械工業出版社, 2005

[2] 劉曉華等.J2EE企業級應用開發[M].北京:電子工業出版社,2003.

第7篇：分布式系統設計原則范文

電力行業是關系到國計民生的基礎性行業，在改革開放30年中，電力行業發展取得了巨大的成就，電力硬件設備急速增長的同時，員工數量也得到了壯大，對人員的管理提出了更高的要求，特別是對具有特殊資格證的人員要求更高。目前的管理方式還處于比較落后的人工和半人工管理階段，特別對野外施工人員的管理更不到位，經常發生串崗、替崗事件的發生，給安全生成帶來很大的安全隱患，特別是輸電檢修人員沒有登高資格證也上塔冒險作業，發生人身傷亡事故責任劃分不清的問題出現。為了解決串崗、替崗事件的發生，同時也為了加快電力行業信息化建設步伐，迫切需要研發人員唯一性身份認證系統，對電網的安全運行具有重大的實際意義。

2研究的目的和意義

2.1電力工程施工現場人員持票狀態智能核查系統目的

利用計算機網絡通信、無線通訊網和模數信號處理以及無線射頻智能識別等技術的最新成果實現施工人員唯一性身份管理，規范施工單位施工中用人規范性管理，防止串崗和沒有資質的人上崗違規施工。

2.2電力工程施工現場人員持票狀態智能核查系統意義

電力工程施工現場人員持票狀態智能核查系統可實現智能電網狀態檢修人員身份認證從傳統管理方式向電子信息化管理方式轉變，實現智能電網狀態檢修人員唯一性身份認證，杜絕沒有資格的人員上崗，同時也可以防止串崗的情況發生。電力安監督察員通過便攜識別儀識別出施工人員或檢修人員是否違規操作。為事故劃分清責任提供了唯一性證據。對違規施工、違規用人起到了震懾作用。

3系統的研究與實現

3.1三層結構的B/S體系模式

3.1.1三層體系構造

關于三層體系成分的作用，它基于以前的二層結構體系之上，同時進行開發和不斷進步的。在以往應用系統研發時，二層的CLIENT/SERVER體系結構應用得很廣泛。其特點為：一般在于客戶和服務器的兩端，有分布著應用程序邏輯，同時還能看到在客戶端，有數據資源訪問的要求，于是在服務器端，把結果向客戶端進行返回。然而，此方法Client/Server組成中存在構成體系上，存在著很多的問題。例如：（1）服務器端的功能在客戶端數目激增時會因為負載過重而大大效率降低。在服務器和客戶兩端，其于應用需求有了變化的時候，應用程序一般都要進行修復，這樣，就給維護，還有升級，都產生了很大的不方便。（2）因為數據傳輸的增多，使網絡負載也變得越來越重了。三層體系結構于數據庫和客戶端間，有一個“中間次層”的加入。通常三層體系表示的是物理三層，而不是簡單地把三個層次疊加起來；三層體系層次，不單是B/S的應用，不是說只有這樣才能算得上三層體系結構。其應用程序為數據訪問、業務規則的處理、合法性校驗等方面的應用，同時在中間層次進行這些應用的處理。通常條件下，用戶端通過Com/Dcom通訊與中間層建立連接，再經由中間層和數據庫做交互，而不直接與數據庫進行交互。

對三層體系結構的支持

以前我們使用ASP，把WEB頁面表現和處理邏輯相互結合起來。如此，一方面對于編輯的調試非常不利，二方面對于擴展也不方便。有兩個好處，一是很快地進行編譯的執行，二是能夠進行頁面與代碼分離，更有其支持事件的每一樣的WEB組成。此形式與和相比于以往的編寫網頁的方法，明顯有了質的飛躍。現在，分布式的對象技術慢慢變得進步了很多，多層分布式的應用，這一體系方式得到了很大的應用，非常廣泛。應用系統利用于多層次的分布式的變化，后來就能夠把C/S組成上的難題給解決了。利用分布式這一技術，可以把異構平臺達到這個目的，它把在對象之間的相互通信變成了可能。把應用系統在分布式系統的情況下集成，如此，把可擴展性也增加了，因為高效性的系統也有了保障。“應用服務器”是于多層次分布式的應用里面，還有于服務器與客戶端的當中，有一層或者二層往上的應用服務程序的加入。利用應用的商業邏輯置于中間層上，開發人員能夠把應用的業務邏輯和用戶顯示界面一一進行區別出來。基于客戶端功能的保證，使用戶有了一個方便的界面能夠顯示得出來。從而降低了技術開發人員的工作量，相對的提高技術開發人員的工作效率。讓開發人員能把所有的心思都放在對于應用系統關鍵的業務邏輯的掌握、研發上，使得應用系統的更新、升級和研發變得不那么緊要了。

3.2系統可行性分析

電力工程施工現場人員持票狀態智能核查系統投入使用后能帶來很高的直接和間接經濟效益、社會效益。有效的防止了沒有施工資質的人員施工檢修，有效防止違規施工及時發現和排除安全事故隱患，減少人為事故和人身傷亡事件的發生。保證了施工的進度，保證了施工質量。保證了供電線路的安全運行。電力工程施工現場人員持票狀態智能核查系統的研究研制成功并穩定上線運行具有很強的復制性，電力系統任何單位和部門對人員身份要求嚴格或苛刻的都使用本系統，因為本系統對人員認證唯一性，而且腕帶射頻標簽設計成手表模樣，帶上美觀大方，戴到手腕上后不能自己摘下除非暴力拆除，但是一旦暴力拆除標簽立即報警并失去腕帶標簽內存儲的個人身份信息，此標簽不能在使用必須從新寫入個人身份信息并賦予權限才可以從新使用，不能暴力拆除但可以被授權能打開的人員順利打開。杜絕身份標簽被借用，完全做到唯一本人使用。特別適合無人變電站巡視員，高危險需要特殊資質的人員等等。對電力系統內部安保有重大意義。

3.3開發方法及總體架構設計

電力工程施工現場人員持票狀態智能核查系統軟件的開發是一項涉及管理科學、信息科學、計算機通訊科學與自動識別技術等多個學科深入交叉的系統工程開發課題，需要一套科學、合理、實用的包括人員的組織與管理、系統開發方法等在內的工程化開發方法和管理制度。確立科學、合理的工程化開發方法，目的在于減少或消除系統開發的風險，保證系統開發成功。智能電網狀態檢修備件智能管理系統采用自頂而下設計、自底而上實施的原則，開發方法是采用生命周期法和快速原型發相結合的方法，最大限度保證系統開發成功。

3.3.1關于防拆卸報警標簽的設計與實現

防拆卸報警標簽實現主要采用技術成熟的無線射頻識別技術實現。防拆腕帶采用手表表帶型設計，腕帶內部有電路一旦被非法打開就立即報警并且這個標簽內存儲信息丟失標簽失去作用，必須從新寫入信息才能使用。腕帶卡扣采用電子密碼鎖或機械鎖設計只有授權的人員才能打開。

3.3.2關于電力工程施工現場人員持票狀態智

能核查系統中間件的開發與實現電力工程施工現場人員持票狀態智能核查系統中間件是位于平臺(硬件和操作系統)和應用之間的通用服務，這些服務具有標準的程序接口和協議。針對不同的操作系統和硬件平臺，它們可以有符合接口和協議規范的多種實現。要具有通用性和可擴展性，方便以后跨平臺復制。電力工程施工現場人員持票狀態智能核查系統無線射頻識別中間件扮演射頻標簽和應用程序之間的中介角色，從應用程序端使用中間件所提供一組通用的應用程序接口（API），即能連到射頻標簽讀寫器，讀取射頻識別標簽數據。這樣一來，即使存儲射頻識別標簽的數據庫軟件或后端應用程序增加或改由其他軟件取代，或者讀寫射頻識別標簽讀寫器種類增加等情況發生時，應用端不需修改也能處理，省去多對多連接的維護復雜性問題。電力工程施工現場人員持票狀態智能核查系統無線射頻識別中間件遵循EPCglobal標準和OSGi構件化標準的無線射頻識別中間件構件化方案，基于Eclipse開發環境與OSGi框架實現無線射頻識別中間件開發平臺，提出了模塊化劃分方法、構件化設計和實現策略，構建了中間件與典型應用的基礎構件庫。本平臺將支持CBSD流程的各種功能集成到統一的桌面環境中，包括：構件選取、組裝、與部署等，支持對無線射頻識別中間件產品及基于無線射頻識別中間件的應用系統的開發以及二次開發。

4總結

電力工程施工現場人員持票狀態智能核查系統投入使用后能帶來很高的直接和間接經濟效益、社會效益。有效的防止了沒有施工資質的人員施工檢修，有效防止違規施工及時發現和排除安全事故隱患，減少人為事故和人身傷亡事件的發生。保證了施工的進度，保證了施工質量。保證了供電線路的安全運行。項目研制完成后投入試運行，重點檢驗和完善系統的精確度和穩定性，產品改進成型后，通過專業技術雜志宣傳及文章交流和研討會等形式使廣大電力局負責人了解該系統，吸引更多單位試用該系統。

作者:邱燦樹 張健權 余少杰 單位:廣東電網潮州潮安供電局

參考文獻

[1]陳清江.輸電線路在線監測技術的研究及應用[J].低碳世界,2013(22).

[2]王文華.淺談OCR技術的發展和應用[J].福建電腦,2012(06).

[3]李艷紅.淺析WebLogic服務器上異步消息的接收.煤炭技術,2013(01)．

[4]孫沛.基于Web的ERP系統的設計與實現[J].科技信息,2010(04)．

[5]劉賽君,常,劉海豐.基于javaEE技術的網絡課程資源管理系統設計[D].天津工程師范學院,2008(03).

第8篇：分布式系統設計原則范文

關鍵詞:協同;電子政務;多Agent;CORBA

中圖分類號:TP391文獻標識碼:A

文章編號:1004-373X(2009)20-093-04

Research on E-government System Based on Multi-Agent Technology

YANG Yucui,SUN Hongbing

(Huaiyin Teachers College,Huaian,223001,China)

Abstract:Implementation of E-government can promote the construction of government information and optimize the Government's organizational structure and business processes.E-government system design requires excellent software systems support.In this paper,a complex E-government system is researched based on multi-agent technology.It is decomposed into a number of modules which are easy to be realized.These modules are designed as society agents.Through the collaboration among these agents,the function of E-government system is achieved.The design idea and system model of E-government system are proposed in detail.

Keywords:collaboration;E-government;multi-Agent;CORBA

0 引 言

在當前網絡化、信息化、全球經濟一體化的趨勢中,政府信息化作為國家信息化的基礎,直接影響國家的競爭力和社會經濟的發展進程。一個國家的信息化發展水平直接關系到該國在未來世界經濟和政治格局中的地位,信息化建設事關國家的核心競爭力,我國在失去工業化先機的前提下,能否抓住信息化的后發優勢,是舉國關注的焦點。政府是信息化進程的先導,必然要求電子政務先行。

電子政務就是以政務信息資源的開發和管理為切入點的,通過集成和應用現代信息技術,以增強政府的調控能力,改進決策質量,降低行政成本,改善工作效率和提高廉潔程度為重點,優化政府的組織結構、業務流程和工作方式,以直接、非接觸和虛擬的方式,向社會提供全方位與跨部門、超越時間與空間、行為規范與透明、符合法律與國際慣例要求的管理和服務。電子政務的過程就是工業時代的政府(即傳統政府)向信息時代的政府(即現代政府)轉變的過程[1-3]。

從技術的角度看,電子政務是基于Web技術、數據庫技術、全文信息檢索技術、GIS技術、RS技術、GPS技術、數據倉庫和數據挖掘技術、空間數據挖掘技術、空間決策技術、數據通信技術、標準化技術、信息安全技術和信息共享技術等于一體的政務信息管理系統。電子政務是科技創新的核心內容,其技術滲透作用對生產力要素、生產方式創新的影響的最為深刻。它為企業、行業或領域信息化提供良好的配套環境,提高社會公眾對信息化的認知程度,實現信息增殖效應。隨著信息技術的發展,各個政府部門紛紛建立了自己的電子政務系統。但是由于各個電子政務系統之間不能相互交流,產生了很多“信息孤島”。為了消除“信息孤島”,創建電子政務應用系統平臺是很關鍵的[4]。需要圍繞機關中對產生的信息資源進行采集、整合、交換、管理、、檢索與內容挖掘。以分布式數據庫為主體,通過統一標準交換協議與關系數據庫網關全面整合、管理,并共享各種信息資源,建立政府機關基礎政務辦公信息資源庫、政府公共信息資源庫和統一的數據交換平臺,構筑分布式、“一站式”的電子政務應用系統平臺,實現各異構政務系統平臺之間的互聯互通,實現各類信息資源庫的全面共享與互操作,達到政府機關信息服務個性化與智能化的目的。另外,在電子政務系統開發過程中還必須考慮病毒、黑客的入侵與破壞,設計時必須考慮相關的安全策略。傳統的開發技術對這樣大型復雜系統的開發面臨著許多困難,如各種信息的實時傳輸與處理、多個功能模塊的協調工作等[5]。人工智能領域的多主體(Multi-Agent)協作技術不僅能有效處理分散的、分布的、不同種類的在線信息資源,而且可作為構造大型、復雜、強健的分布式信息處理系統的框架結構。為此,將多主體技術引入電子政務系統的開發領域,成功解決了各功能模塊的協作難題及入侵檢測難題,對電子政務系統的開發有一定的借鑒意義。

1 多主體技術簡介

Agent一詞的中文意思是“”或“主體”,是一種在分布式系統中能夠自動、自主地感知環境,并作用于環境的硬件或軟件實體,其主要作用是提供一種易于理解和使用的操作界面,接受用戶的指令,代替用戶完成某些復雜繁瑣的工作,或為用戶提供幫助。其概念最早出現于20世紀70年代的人工智能中,80年代后期開始受到重視。Agent可以實現分布式查詢和計算,實現高層服務的低層分解,它還可以自定義一種Agent腳本語言,供用戶提供高層要求,Agent在運行時可以進行效率的權衡,從而避免瓶頸效應。此外,Agent能利用元數據與其他Agent 一起協同工作。從人機工程的角度考慮,賦予電腦或程序更多人性化色彩,如支持語音合成輸出信息、語音識別輸入指令、智能提示、動畫等,能夠充分提高人機交互的有效性和易用性,提高信息處理的柔韌性[5-7]。

多主體(Multi-Agent)技術是為解決大規模復雜問題的智能求解而發展起來的。其基本思想是把大的復雜系統分解為許多小的、可以實現相互通信、能夠彼此協調工作的自治系統(Agent),然后通過這些自治Agent的交互、協作等智能行為完成復雜的任務求解。國內外學者已在Multi-Agent技術應用方面做了嘗試,并取得了一些成果。美國NASA Ames研究中心與JPL聯合構造出了用于深空1號航天器的遠程診斷Agent,能實現航天器自主診斷和修復功能。Kenvin P.Logan等人于2003年提出了針對分布式機械健康監測和診斷系統的智能軟件主體[8-10]。由于多Agent 可以很好地處理分布式事務,在此嘗試利用多Agent的這一特性對電子政務應用系統平臺分解,以得到利于實現的功能模塊(Agent),從而得到一個基于多Agent的電子政務應用系統平臺模型,并對系統的安全性進行必要的設計與分析。測試結果表明,該系統能滿足電子政務系統中各角色的協作與信息交互,能夠有效檢測并抵御不良入侵。

2 基于多主體技術的電子政務系統設計

2.1 電子政務的行為主體及工作模式

在電子政務系統開發過程中,必須先進行需求分析,再確定系統功能及系統角色(即行為主體)。針對我國政府業務的具體情況,電子政務中的行為主體主要是四個:政府,從中央政府到地方政府;政府雇員;企業及事業單位;社會公眾。由這四個主體形成了電子政務系統應用的四種不同工作模式:

(1) 政府對政府(Government to Government,G2G)。它是異級、異地或異職能部門之間的電子政務,即通過政府之間和機構部門之間的信息交流溝通,打破機關部門的壟斷和封鎖,加速政府內信息的流轉和處理,從而達到共享公共資源,促進協同辦公的目的。其內容包括:電子公文系統、電子法規政策系統、電子司法檔案系統、電子并聯審批系統、電子財政管理系統、電子辦公系統、電子培訓系統、電子資料庫、電子郵遞等。

(2) 政府對公務員(Government to Employee,G2E)。它指政府和公務員之間為提高政府效率服務而建立的基于Intranet的有效行政辦公體系,其目的是通過借鑒產業界的先進經驗(如供應鏈管理、財務管理和知識管理),更好地利用信息技術減少政府支出,改善政府機構的行政管理,使各機構能提高工作效率和改進績效,消除工作拖沓現象,同時改善公務員的滿意度和忠誠度,營造和諧良好的組織文化。其基本內容包括電子公文、電子郵件、電子人事及電子財務等。

(3) 政府對企業(Government to Business,G2B)。它是政府通過網絡為企業提供的公共信息資源,實施基于網絡系統的業務監管與服務,以及電子采購與招標。企業通過獲取政府公開的各種信息資源,可以避免發展的盲目性,將更為容易地找到更多商機。政府對企業業務的監管與服務網絡化,有利于營造公平的競爭環境,最大限度地減少暗箱操作及權錢交易。政府的電子采購與招標,有利于體現公平公正的原則和防止腐敗,大大節約政府部門的運行成本。其基本內容包括:電子采購與招標、電子稅務、電子證照辦理、信息咨詢服務、中小企業電子服務。

由此可見,電子政務不僅是電子商務的基礎支撐和環境保障,而且G2B模式的電子政務還能成為電子商務的業務增長點,實現電子政務與電子商務的共同發展。

(4) 政府對公眾(Government to Citizen,G2C)。它是政府通過網絡系統為公民提供的各種服務。它以公共利益為目標,以社會公眾的客觀需求為尺度,通過以互聯網為平臺的網絡系統,尊重公民意愿,建立和發展廣泛的社會回應機制與公共責任機制,為公民提供各種滿意的公共產品和公共服務,進而提高政府的透明性,強化公民的民主參與和多元監督,促使政府運轉高效低耗和公務員的廉潔自律,其主要內容包括:教育培訓服務、就業服務、電子醫療服務、社會保險網絡服務、公民信息服務、交通管理服務、公民電子稅務服務以及電子證件服務等。

2.2 電子政務系統體系結構設計

依據上述電子政務系統所需提供的功能及各行為主體,結合電子中的幾種工作模式,將整個系統優化分解為易于實現的子系統,這些子系統由相應的智能主體(Agent)來實現。設計的基于Multi-Agent 技術的電子政務應用系統平臺體系結構如圖1所示。

圖1 基于多主體的分布式電子政務系統體系結構

其中,按層次分為政府各級部門提供服務的政府Agent、企業Agent以及面向公眾的公眾Agent。對政府Agent進行細化設計了14種主要的Agent,包括用戶認證Agent、智能處理Agent、檔案管理Agent、智能管理Agent、會議管理Agent、工商審批Agent、管理Agent、決策信息Agent以及信息服務Agent等。各Agent通過CORBA進行協作與信息交流。將企業Agent進行細化,設計了5種主要的Agent,包括用戶接口Agent、招標采購Agent、數據管理Agent、工商稅務Agent以及企業服務Agent等。將公眾Agent進行細化,設計了5種主要的Agent,包括用戶接口Agent、事務辦理Agent、公共服務Agent等。

2.3 主要Agent設計及系統工作過程

在圖1所示的電子政務系統中,各Agent的作用各不相同,限于篇幅,僅介紹幾個主要的Agent功能及作用。

(1)用戶認證Agent。由于系統的用戶包括政府的公務員、社會公眾以及企業等,不同的用戶具有不同的權限。為此,用戶認證Agent 需要通過用戶密碼或者用戶的IP地址等信息對用戶賦予其相應的操作權限。

(2) 智能管理Agent。該Agent 對系統資源進行有效的管理與協作,并對各種事務進行分類,根據類型將事務發送到不同的Agent 進行處理。

(3)信息服務Agent。該Agent 能將用戶端傳來的信息搜索請求提交給數據庫Agent,并進行相應的查詢操作,將查詢結果以約定的形式返回給用戶。

(4)決策信息Agent。該Agent 利用數據挖掘、神經網絡、人工智能等方法,將信息服務Agent、公眾信息管理Agent等送來的信息進行綜合處理,給出用戶所需的決策信息,或者輔助政府機關的各級領導就某一事務進行決策,避免或減少失誤。

(5)公眾信息管理Agent。該Agent 負責實現公眾提交的意見及建議等信息的有效管理,對其進行分類、存儲和組織。并將這些信息傳遞到數據庫進行存儲,同時送決策信息Agent,以輔助政府部門就某一事件進行決策。

(6)用戶接口Agent。該Agent 的功能主要是在政務系統與用戶之間架起聯系的橋梁與紐帶。用戶通過該Agent可以向系統提交請求、意見及建議等信息,同時政府部門的一些反饋信息、建議、意見以及事件的處理結果也通過用戶接口Agent返回給用戶。

(7)數據庫Agent。電子政務系統要處理大量的信息,這些信息包括政府信息和企業及社會公眾的信息。如何對這些信息進行有效的存儲與管理,這對系統的工作速度及穩定性至關重要。一般認為,關系數據庫系統(如Oracle,SQL Server,Foxpro等)適合傳統數據類型(結構化信息)的表示和存儲,但是對復合文檔數據的處理并非能夠完全表達。因此,“面向Agent的存儲技術”的概念就被引入電子政務系統的數據庫領域,其目標就是針對新出現的需求,高效率地表達和存儲管理“復合文檔數據”。當然,傳統數據的存儲和處理也是系統的重要部分。

當用戶端(即公務員或者公眾或者企業等)通過互聯網或政務內部網訪問該電子政務應用系統平臺時,首先通過認證Agent 對訪問者的身份或者地址IP 進行認證,認證通過后,事務交由智能管理Agent 進行處理。如果是查詢事務,則將該事務發送給信息服務Agent。信息服務Agent 向分布式數據庫Agent提交搜索請求,如果搜索成功返回結果;如果搜索不到所需數據,將通過數據挖掘等方法對分布式數據庫進行更復雜的算法搜索,搜索成功,結果返回用戶端,同時將結果傳遞給智能管理Agent及數據庫Agent 進行相應的信息記錄分類,進而存儲到相應的數據庫站點中。如果事務為需要處理的政務事件,將事務發送給相應的處理Agent,如工商審批Agent、會議管理Agent、管理Agent等進行處理,處理結束后將處理結果返回給用戶端,同時也將結果傳遞給政務智能管理Agent進行相應的信息記錄分類,進而存儲到相應的數據庫站點中。如果該事務是用戶提交的一些反饋信息、建議、意見等,則將該事務發送給公眾信息管理Agent,由該Agent 負責對信息進行分類處理,處理結果返回用戶端。對系統進行了實際測試。結果表明,系統能夠有效實現設定的功能。

3 結 語

通過對電子政務系統行為主體及工作模式的分析,在對復雜的電子政務系統進行功能分解的基礎上,用對應的智能主體來實現分解后的子系統,通過這些智能主體的自主運行及相互間的協調協作,有效實現了系統功能。利用ORG的CORBA來實現各智能主體之間的通信,可以有效實現跨平臺操作,為系統的實現及后期升級帶來便利。

參考文獻

[1]王輝,朱慧濤.我國電子政務建設中的障礙與對策[J].安徽大學學報:哲學與社會科學版,2003,27(6):145-151.

[2]郭荷清,吳濤.基于Multi-mobile Agent的決策模型在電子政務中的應用[J].計算機應用與軟件,2007,24(11):109-110.

[3]蘇錦鈿,郭荷清,高英.基于軟件Agent的電子政務安全設計[J].計算機應用與軟件,2006(3):56-58.

[4]徐曉林,楊蘭蓉.電子政務導論[M].北京:北京科學技術出版社,2002.

[5]馮濤,袁占亭.基于技術的電子政務系統研究與設計[J].計算機應用,2003,23(4):19-21.

[6]張鵬程,李人厚,秦明.基于Agent的開放式協同工作系統結構模型[J].計算機應用,2002,22(3):1-3.

[7]Wooldridge M.An Introduction to Multi-agent System[M].John Wiley & Sons,2002.

[8]D.Bernard.Autonomy and Software Technology on NASA′s Deep SpaceOne[J].IEEE Expert Intelligent System,1999,14(3):10-15.

第9篇：分布式系統設計原則范文

關鍵詞：學生檔案管理；數據庫設計；需求分析；客戶端/服務器模式

中圖分類號：TP315文獻標識碼：A文章編號：1009-3044(2008)35-2486-04

The Design and Implementation of Hotan Teachers College Students' Records Management System

ADIL Gulam

(Department of Physics, Xinjiang's Hotan Teachers College, Hotan 848000, China)

Abstract: A new method of student's scores management system forHotan Teachers College is introduced in this paper. combining the design and implementation of student's scores management system ,we have made research on the distributional application system. many universities have been trying to develop an opened and distributed student's scores management system on their campus networks. In this paper, the optimum solutions on scores management system according to the characteristics of Xinjiang special regions are discussed by considering the relations between the network architecture and score management systems.

Key words: scores management system; database design; needs analysis; client/server model

1 引言

學生檔案管理系統是教育單位不可缺少的部分。一個功能齊全、簡單易用的學生檔案管理系統不但能有效地減輕學校各類工作人員的工作負擔，其內容對于學校的決策者和管理者來說也至關重要。所以學生檔案管理系統應該能夠為用戶提供充足的信息和快捷的查詢手段。但一直以來人們使用傳統人工的方式管理文件檔案、統計和查詢數據，這種管理方式存在著許多缺點，如：效率低，保密性差，人工大量浪費；另外時間一長，將產生大量的文件和數據，這對查找、更新和維護都帶來了不少困難。隨著科學技術的不斷提高和計算機科學日漸成熟，其強大的功能已為人們所深刻認識，它已進入人類社會的各個領域并發揮著越來越重要的作用。

基于校園網的學生檔案管理系統完成后可以降低工作量，提高辦公效率，學生管理人員、教師和學生都不受時間和地點的限制查詢學生資料，而目前使分散的學生管理得到集中管理，這對減輕管理工作負擔，提高管理水平，實現學生管理的現代化、系統化、規范化具有重要意義。本文結合和田師范專科學校學生檔案管理工作的實際情況，在需求分析、系統分析的基礎上，對和田師專學生管理系統做出總體設計、詳細設計和程序設計，并進行系統測試。

2 需求分析

這個階段的任務是確定“為了解決這個問題，目標系統必須做什么”，主要是確定目標系統必須具備哪些功能。對于需求分析不僅是軟件定義時期的最后一個階段，而且是軟件開發期的第一個階段，也是關系到軟件開發成敗的關鍵步驟。只有通過需求分析才能把軟件功能和性能的總體概念描述為具體的軟件需求規格說明，從而奠定軟件開發的基礎。在本階段所研究的對象是軟件項目的用戶要求，且必須全面理解用戶的各項要求，但又不能全盤接受所有的要求。為了達到這一目的，必須對其中模糊的要求進行澄清，然后才能決定是否可以采納。而且準確地表達被接受的用戶要求，也是需求分析的另一個重要方面，只有經過確切描述的軟件需求才能成為軟件設計的基礎。

2.1 學生檔案管理系統的功能

學生檔案管理系統旨在提供一貫可以操作的，方便管理，提高工作效率，易于修改的輔助管理系統。考慮到我校校園網落的實際情況，本系統采用Visual Basic+SQL Server 2000 結構。

考慮到系統所要實現的功能以及系統的安全性，在用戶進入系統之前進行合法用戶檢測。所以系統中應該有一個用戶名和密碼檢測的模塊，當然與此相對應，還必須有操作員管理模塊，它必須能夠進行操作員的增加、刪除和修改，并且能夠進行授予相應的操作權限。系統中必須有一個默認的管理用戶，它在應用系統剛安裝好就能夠使用該用戶進入，該用戶能夠建立其他用戶。同時還必須有密碼修改的模塊。普通用戶能夠修改自己的密碼，但系統管理員用戶能夠修改所有的資料。

大中專學校的學生檔案管理內容十分豐富，工作繁多，所以本例規定開發的學生檔案管理系統只處理每學年的招生信息導入、新生學籍注冊、學生檔案管理和其它管理。

在招生信息導入管理方面提供的服務功能如下：

1) 導入新生的民族、籍貫、專業代碼；

2) 錄入院系信息和生成班級信息；

3) 導入招生數據和新生圖片；

4) 統計和清除新生數據；

5) 修改密碼。

在新生學籍注冊管理方面應提供的服務功能如下：

1) 新生入校學籍注冊；

2) 新生專業調整；

3) 新生統計與報表生成以及報表打印；

4) 修改密碼。

在學生檔案管理方面應提供的服務功能如下：

1) 錄入學生每學期的情況；

2) 生成學生鑒定表；

3) 生成回執單；

4) 檔案查詢及打印；

5) 修改密碼。

學生檔案管理系統的直接用戶有學生、教師和教學管理員。管理員有權操縱數據庫的數據，進行添加、更新、刪除等操作。學生和教師一般只查詢信息。本校的各部門，教研室、學生幾乎有PC機，學校全部計算機已經連網。

2.2 學生管理主要工作流程分析

學生管理的各項工作之間有嚴格的順序性，這就要求在開發時對學生管理的業務流程有明確的了解。學生管理工作中的運行管理是核心工作，就對運行工作中涉及的業務流程進行分析。具體的業務流程圖如圖3、圖4所示。

3系統設計

3.1 設計思路

基于C/S的學生檔案管理系統的設計是一個不斷改進和反饋的過程。圖8是進行基于C/S的學生檔案管理系統的設計思路圖。

1) 系統界定

首先必需對系統進行界定，即劃分系統的范圍，分析系統與其他系統之間的關系、系統與環境的關系。如圖5，這個過程產生對系統的一個清晰的描述，確定研究的問題。

2) 系統規劃、分析和方案設計

針對一個已經界定清楚的系統，下面的工作便是進行系統的規劃和分析及設計方案。在這個過程中，首先對系統進行規劃，進行了子系統的劃分和系統的實施計劃的設計，同時對系統進行分析，這些分析包括系統的特性和結構的分析、需求分析、系統的可行性分析等內容，系統規劃和分析經常交織在一起。另外，在這個階段還完成系統方案的設計和選擇工作。

3) 系統概要設計

系統概要設計主要是對系統業務進行流程分析，完成系統的特性設計以及系統的功能劃分和初步設計，并對系統具體結構和技術方案進行設計。

4) 系統詳細設計

系統詳細設計包括數據流的設計、數據庫的設計、系統模塊的詳細設計、界面設計、程序流程的設計等內容。

5) 代碼開發

代碼開發是按照詳細設計的要求進行代碼的編寫工作。

6) 系統測試

系統測試是在系統投入使用前，對系統的需求分析、設計規格說明和編碼的復審。

7) 系統修改、運行和維護

維護系統的運行，保證系統有效、可靠的運轉。

8) 系統評價和總結

對系統的完成和運行情況進行評價，總結系統開發過程中的得失，有些好的體會、思想和資源可以積累下來，并且這個過程還可以對系統的改進和再設計進行分析。實際上，以上這些過程并不要求嚴格按順序的，前后過程之間存在反饋，這些過程之間并不一定存在明顯的界限。

3.2系統功能模塊設計

對上述各項功能進行集中、分塊，按照結構化程序設計的要求，學生檔案管理系統需要完成的主要功能有以下幾大模塊：

1) 招生信息導入

新生數據和圖片導入、新生數據統計，輸入院系和班級信息，導入民族、專業、籍貫信息，查詢新生信息以及密碼管理等功能。

2) 新生學籍注冊

學籍注冊，分班，自動生成學號，圖片下載，手工輸入，調動學籍、學籍統計和查詢，打印個人信息表和統計表、密碼管理等功能。

3) 學生檔案管理

學生檔案查詢、統計、生成花名冊、打印個人信息表、打印學生證、打印花名冊、打印統計表、回執單以及自定義表格打印

3.3 數據庫設計

進行數據庫的概念設計，首先必須選擇適當的數據模型。用于概念設計的數據模型既要有足夠的表達能力，可以表示各種類型的數據及其之間的聯系和語義，又要簡明易懂，能夠為非專業人員所接受。可供選擇的數據模型不少，比如各種語義數據模型、面向對象數據模型等，目前應用最廣泛的是E-R數據模型（Entity-Relationship data Model）。必須根據需求分析，確定E-R模型中的實體、聯系和屬性。

首先要確定學生檔案管理的實體，從前面章節的分析中可以看出，所有的活動都是以學生基本信息（Student）展開的，初步確定有以下實體：用戶（UserID）實體、專業代碼實體、地區代碼實體、民族代碼實體、院系代碼實體、政治面貌代碼實體、班級實體，其中專業代碼實體、地區代碼實體、民族代碼實體、院系代碼實體、政治面貌代碼實體、班級實體、完全依賴于設備實體的存在而存在，所以屬于弱實體的范疇。

其次要確定學生管理中各實體的鍵、屬性、屬性的數據類型及取值范圍。在確定實體的主鍵時，要確保這個主鍵可以唯一的標識這個實體。在概念模型的設計中，經常會遇到這種情況，最簡單的解決方法就是對實體集合中每個實體有一個互不相同的學號，選擇這個學號作為實體集合的關鍵字。因此在學生基本信息實體中增加了學生學號這個屬性，這種增加學號屬性也是設計中常用的一種確定實體鍵的方式。在確定實體的屬性及其數據類型時，要考慮到系統的可擴展性以及特殊情況。在確定屬性代碼的時候，要避免同一概念數據模型中出現相同的屬性編碼，同時還要使人一目了然。在這里給出各實體的屬性和主鍵，以下劃線標識出主鍵。

學生基本信息實體：考號、學號、院系代碼、專業代碼、現在專業、班級編號、現在班級、姓名、性別、出生年月、政治面貌編號、婚姻狀況、家庭出身、戶口性質、畢業中學、考生設備名稱特長、家庭地址、聯系電話、郵編、入學日期、高考成績、Picture.

專業代碼實體：專業代碼、專業代號、錄取專業、院系。

地區代碼實體：區號、籍貫。

民族代碼實體：民族代碼、民族。

院系代碼實體：院系代碼、院系、院系主任。

班級實體：班級編號、院系、錄取專業、班級、班主任。

用戶實體：用戶名、密碼、權限。

第三要確定實體之間的聯系。實體與實體之間的聯系除了一對一、一對多之外，還存在有多對多的形式。可以將聯合理解為構建于M:N聯系實體之間的一個橋梁，通過它將這個M:N聯系轉化為兩個1:N聯系。完成了學生檔案管理模塊的概念數據模型之后，可以用相同的步驟來完成系統中其他模塊的概念模型的設計，在這里就不一一贅述。

4 系統實現

系統的實現選用Microsoft Visual Basic 作為前臺開發工具。Visual Basic 是一套完整的開發工具，提供了企業級模板。系統采用多層結構設計，可以生成具有高度可伸縮性和靈活性的應用程序。使用Visual Basic架構開發，生成可編程Exe窗體，Visual Basic界面與代碼相分離。

4.1用戶注冊與登錄模塊的實現

每個模塊的登陸界面以及密碼算法是統一的，但是所運行的模塊不同，所訪問的數據庫不同，因此登陸用戶身份以及密碼不同，如圖7。

4.2 招生信息導入模塊的實現

界面實際上是系統與用戶之間的接口，也是控制和選擇信息輸入輸出的主要途徑。界面設計規定界面的布局、風格、色彩等約定，界面設計應該堅持友好、簡單、實用、易于操作等的原則。

這個模塊的主要功能是，把招生的信息導入到招生數據庫中，以便于學生學籍注冊時使用。

4.3 學籍注冊模塊的實現

這個模塊的主要功能是，新生到校報名時，根據考號調用相關信息，并分班，同時自動生成學號后，保存到學生檔案數據庫中，以便于學生檔案管理時使用。

圖9 學籍注冊模塊的實現

4.4 學生檔案管理模塊的實現

這個模塊的主要功能是，輸入學生每學期獎懲情況、政治思想狀況、以及修改、查詢學生相關信息。打印院系學生花名冊、個人信息表、回執單等，如圖10。

5 結束語

本論文結合和田師專學生檔案管理系統的設計與實現，研究了基于C/S的分布式應用系統原理、設計和實現的問題。首先，論文概述了和田師范專科學校學生檔案管理系統的應用背景，對學生檔案管理系統進行了需求分析。在此基礎上提出了基于C/S的分布式應用系統的解決方案。接著，論文對學生檔案管理系統的解決方案─基于C/S的分布式應用系統的結構和原理進行了深入研究，并從系統的角度對基于 C/S 的分布式系統的特性進行了分析。在論文中，結合筆者實際研究過程中的經驗，對基于 C/S 的分布式應用系統的設計方法進行了研究，提出了基于校園網的一些安全和復合密碼算法思想，并給出了基于 C/S 的分布式應用系統的設計流程。最后，論文對學生檔案管理系統進行了詳細設計和實現，重點分析了學生檔案管理系統的技術方案設計和應用平臺選擇、系統設計以及系統的實現。

參考文獻：

[1] 王行言,俞盤祥.計算機信息管理系統[M].北京:高等教育出版社,2000:58-153.

[2] 鄧亞平.計算機網絡安全[M].北京:人民郵電出版社,2004:284-287.