分布式系統設計與應用精選(九篇)

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

第1篇：分布式系統設計與應用范文

【關鍵詞】分布式光纖測溫；拉曼散射；OTDR；溫度；電纜

物聯網是繼計算機、互聯網與移動通信網之后的第三次信息技術革命，將成為下一個萬億級美元以上的產業，傳感技術作為物聯網中的物理感知和數據采集層，為物聯網提供最基礎的物理信息數據，構成物聯網的基礎和核心。基于拉曼散射的分布式光纖測溫系統作為物聯網感知層設備，可以利用光纖作為溫度信號的傳導介質，測量沿光纖走向的連續空間內溫度場的分布情況。通過高速采集卡采集攜帶溫度信息的數據，并將采集到的數據進行同步累積，數字累加和小波變換的處理，去除噪聲的干擾，并通過OTDR解調準確地得出光纖沿線上任一點被測量在時間和空間上的信息分布，具有抗電磁干擾強、靈敏度高、耐腐蝕、本征安全、測量距離長、定位精度高、使用壽命長等優勢。

1 分布式光纖測溫系統工作原理

基于拉曼散射的分布式光纖溫度傳感器是基于光纖內部的拉曼散射現象的溫度特性，利用光時域反射測量技術（OTDR），將較高功率帶電光脈沖送入光纖，然后將返回的散射光強隨時間的變化探測下來。分布式光纖溫度傳感器基于背向散射或者前向散射機理，其中背向散射具有溫度測量的實際意義，若能測量出背向散射光的強度，就可以計算出反射點的溫度，這就是利用光纖測量溫度的基本原理[1-2]。

入射光子與介質分子在光纖纖芯介質材料密度的成分起伏和微觀變化等因素的影響下，二者相互作用，入射光中光子與分子由于介質的非線性效應而發生非線性碰撞。光子與分子之間在非彈性過程中發生能量交換，光子不僅改變了運動的方向，同時光子的部分能量傳遞給分子，或者分子振動和轉動的部分能量傳遞給光子，從而改變了光子的頻率，這就是拉曼散射[2]。

因為光纖具有一定的長度，且拉曼散射是產生在光纖中的每一個微觀點的，所以如何確定我們探測到的拉曼散射在光纖中發生的位置就需要用到光時域反射技術[3-5]。

光時域反射技術（OTDR）最初用于評價光學通信系統中光纖、光連接器等的性能，是用于檢驗光纖損耗特性、光纖故障的有效手段，同時也是分布式光纖傳感器的基礎[6]。光源發射出一系列的激光脈沖進入光纖中，它們會在光纖中產生背向散射。在時域中，入射光經后向散射返回到光纖入射端所需的時間為t，激光脈沖在光纖中所走過的路程為2L，2L=v？鄢t，v=C/n，其中v為光在光纖中的傳播速度、C為真空中的光速、n為光纖折射率。在測得時刻t時，就可求的距離光源L處的距離。

圖1 OTDR原理框圖

圖1中的主時鐘產生標準時鐘信號，脈沖發生器根據這個時鐘產生符合要求的窄脈沖，并且它來調制光源；光定向耦合器將光源發出的光耦合到被測光纖，同時將散射和反射信號耦合進行光檢測器，經放大及信號處理后送入示波器，顯示輸出波形及在數據輸出系統輸出的有關數據。要進行信號處理的原因是后向散射光非常微弱，淹沒在噪聲中，只有采用取樣積分器對微弱散射光進行取樣求和，隨機噪聲抵消，才能將散射信號取出。

2 系統主要功能

1）實時數據采集：能夠實時的采集光纜沿途的溫度，形成實時數據庫。

2）實時數據顯示：顯示電纜的實時溫度[7]。

3）升溫速率報警：當電纜達到用戶要求設置的升溫速率預訂值時，可以報警、指出報警電纜處位置、數據存儲和打印[8]。

4）超溫報警：根據用戶要求設置報警和預警溫度警戒值，并且可實現電纜分段報警，對電纜的不同部分實施不同標準的報警設置。

5）特性曲線顯示：包括某一時段電纜某點的溫度變化曲線、某時段電纜溫度變化曲線、某時段電纜某點的最高溫度變化曲線和某日電纜最高溫度分布曲線等。

6）歷史數據顯示：用戶可以通過歷史數據查詢得到電纜某時刻溫度、某日電纜某點的溫度、某時刻電纜某點的溫度、某日電纜最高溫度及某時刻電纜某點的最高溫度。

7）遠程監控：通過Internet可對現場設備實施遠程監控、診斷和維修等。

3 系統結構及工作機理

基于拉曼散射的分布式光纖測溫系統分為硬件與軟件兩大部分（見圖2）。硬件主要有激光器、雙向耦合器、光電雪崩二極管、放大器、信號采集處理卡、DTS主計算機和工控機等組成。軟件由采集端程序和分析段程序組成，分別運行在兩臺PC機上，通過TCP/IP協議完成通信。采集端程序運行平臺通過與信號處理卡通信，讀取卡狀態、相關數據，通過運算，計算得出電纜各點的溫度值，并將數據發送到分析端，同時在界面顯示；分析端程序運行平臺通過Internet接收所采集的溫度數據，通過運算，根據預先設置的報警值，產生報警并在圖形界面顯示，所采集的數據同時被存入相應的實時數據庫。傳感光纜既是傳輸載體優勢傳感媒體，可以把監測對象的溫度的實時情況反饋到主機。

圖 2 基于拉曼散射的分布式光纖測溫系統結構圖

工作機理：當被監測對象發生溫度變化時，傳感電纜會感受大溫度的變化并隨之改變。光纖中背向散射光的強度被調制，并被波分復用器分開成斯托克斯光宇反斯托克斯光，光電雪崩二極管和放大器分別對這兩種光進行接收放大處理，然后經信號采集處理卡后，由DTS主計算機進行解調和數據處理，將被測對象上各點的溫度信息實時地提取并存儲。由工控機對這些數據進行管理，以實現分析、報警。實時顯示和查詢等功能。

4 工程應用

本系統被某省電力公司安裝在220kV玉賢至七里廟輸電線路上，實現對2回路（玉墨一回、玉墨二回）中的四根電纜（每根電纜長度約5.6km）的表面溫度信息的數據采集、數據存儲、數據查詢、遠程監控等功能，從系統主要功能上分為數據采集和數據監控。數據采集端相當于系統的數據服務器負責數據的采集和存儲。監控端相當于終端負責對采集到的數據進行圖形化展示、監測、查詢、分析。通過實時溫度監測，可以及時發現潛在危險，發出報警信息，避免電力事故發生，提高電纜的運行安全性和可靠性。

待工程施工及軟件配置完成后，系統進入正常運行狀態，通過觀察監控界面（見圖3）的實時數據，可以時刻掌握被測電纜的運行狀態。

圖3 分布式光纖測溫系統監控界面截圖

圖4 玉墨1回路A相電纜溫度實時曲線

圖5 玉墨1回路C相電纜溫度實時曲線

圖6 玉墨2回路A相電纜溫度實時曲線

圖7 玉墨2回路C相電纜溫度實時曲線

圖4-圖7顯示了項目名稱、工控機CPU的使用率與內存的使用率、DTS分布式距離至用戶對象距離的映射圖、玉墨1回路A相和C的分布式溫度信息、玉墨2回路A相和C相的分布式溫度信息、通過觀察這些信息，可隨時掌握電纜的運行溫度、溫度曲線等狀態信息。

一旦電纜的發生局部過熱，將在監控界面上顯示出溫度異常信息，彈出報警信息框，并且觸發聲光報警器，啟動短信模塊，發出報警信息。

通過分布式光纖測溫系統對電纜運行狀態的溫度信息進行實時監測，及時發現潛在故障，采用多種報警方式提醒用戶，以便盡早采取行動，避免事故發生。

5 結論

基于拉曼散射的分布式光纖測溫系統能夠實時提供待測對象全程的表面溫度、導芯溫度、接頭溫度等信息，且具有抗干擾、本征安全、測量距離遠、精度高、定位準等優勢，是電力電纜、橋梁、隧道等領域在線狀態監測的最佳手段。通過在電纜上安裝分布式光纖測溫系統，能夠為用戶提供電纜實時運行狀態信息，及時發現潛在異常點，實現故障早期預警，防止和杜絕電力事故發生，保證監控對象運行的安全性和可靠性。

【參考文獻】

[1]劉媛，張勇，雷濤，等.分布式光纖測溫技術在電纜溫度監測中的應用[J].山東科學，2008，21（6）：50-54.

[2]張在宣，王劍鋒，劉紅林，等.30km遠程分布式光纖拉曼溫度傳感器系統的實驗研究[J].中國激光，2004，31（5）：613-616.

[3]張在宣，張步新，陳陽.光纖背向激光自發啦曼散射的溫度效應研究[J].光子學報，1996，25（3）：273-278.

[4]陳軍，李永麗.應用于高壓電纜的光纖分布式溫度傳感技術[J].電力系統及自動化學報，2005，17（3）：47-49.

[5]何明科，張佩宗，李永麗.分布式光纖測溫技術在電力設備過熱監測中的應用[J].電力設備，2007，8（10）：30-32.

[6]彭超，趙建康，苗付貴.分布式光纖監測技術在線監測電纜溫度[J].高電壓技術，2006，8（32）：43-45.

第2篇：分布式系統設計與應用范文

分析了我校網絡數字化實驗室的管理現狀和存在的問題，提出了實驗室數字化管理的必要性，分析了分布式管理系統的架構及存在的優點和缺點，提出將Agent技術用于計算機網絡實驗室的數字化管理系統中的可行性.

關鍵詞：

分布式系統；數字化實驗室管理；Agent技術

隨著我校數字化校園建設規模的擴大，數字化實驗室越建越多，在各學科教學改革中的作用也越來越明顯.如何管理好這些實驗室，為學科教學提供良好的軟硬件環境，讓它們發揮更大的作用，是擺在我們面前的問題.

1我校網絡數字化實驗室的管理現狀

目前，我校的數字化校園建設已經初具規模，但是我校實驗室的管理還停留在傳統的管理模式即人的管理上：上機記錄需要人來填寫；安排上機需要人來安排；計算機出現故障時不能及時發現，需要老師檢查才能發現；學生上課時玩游戲難以控制；實驗室的設備也沒有防火防盜設施等等.如何解決這些問題，使數字化實驗室的管理規范化，就需要我們探索出一個適合的、功能全的系統.

2分布式數字化實驗室管理系統

計算機實驗室的管理由傳統的管理模式向先進的數字管理模式轉變，由最初的單一管理功能轉變為多樣化管理功能，由單個計算機實驗室管理轉變到全校分布式互聯計算機實驗室統一管理，這要求采用多種先進的軟件技術，構建一個分布式數字化共享管理軟件平臺，包括統一實驗室管理、上機認證、多媒體教學、網上行為等，提供統一的認證入口，并且和我校現有的一卡通和網絡身份認證系統接軌.分布式管理系統是建立在計算機網絡基礎之上，具有高度的內聚性和透明性，它涉及到多個計算機實驗室、成百上千臺計算機和多臺服務，為了確保計算機之間的通信暢通無阻，系統采用了C/S（客戶機/服務器）模式，用Socket多線程和多端口技術編程，以保證多臺計算機、多個用戶之間的正常通信.

2.1系統設計

分布式管理系統要求所有的計算機數字化實驗室管理采用統一平臺，一個后臺數據庫，放在網絡中心集中管理.數據庫不對實驗室公開，實驗室只負責教學及實驗管理和學生自助上機.整個系統的框架圖如下圖所示：

2.1.1硬件組成

分布式管理系統的硬件主要由主服務器、各實驗室服務器、學生用計算機、監控機、刷卡機等組成.主服務器安裝SQLServer數據庫和主服務器端程序，主服務器中存儲全校師生的基本信息數據和全校的計算機專業課和公共課課表以及實驗安排表；各實驗室服務器安裝SQLServer數據庫、實驗室服務器端程序，并和刷卡機相連，這個服務器負責學生的刷卡注冊并記錄學生們的上課和實驗情況，并且和主服務器進行數據交換；監控機安裝監控程序，實時監控火警、盜警以及學生是否玩游戲等情況；學生機安裝客戶端程序，將學生的上課及實驗信息傳回實驗室服務器，并且受控于監控機.

2.1.2軟件設計

分布式數字實驗室概念就是集成多種軟件技術，包括集成了底層管理、內核保護、動態屏幕截取、屏幕監控、網絡阻斷等多種軟件技術，更好地完善數字化實驗室的專業管理，以解決數字化實驗室的統一管理、信息認證、多媒體教學、網上偵聽及阻斷等多種專業的管理要求.

2.1.2.1系統程序的構建與設計

分布式管理系統是多個計算機的統一整體，成百上千臺計算機和多臺服務器分布在不同實驗室.所以根據這樣的分布式特點，管理系統基于Win-dows7操作系統平臺，采用C／S（客戶機/服務器）模式，并且應用VC++軟件進行編程.整個系統主要分為主服務器端、各實驗室服務器端、學生端和監控端，通過VC++和Socket多線程網絡編程使系統各部分有序地結合在一起，以完成系統的相應功能.

2.1.2.2數據庫的組建

分布式系統采用SQLServer組建數據庫，并使用ADO數據訪問技術與各程序相連，根據分布式管理系統所要實現的功能，在數據庫中建立相關的表，主要的數據表如下表所示.

2.1.2.3數據的備份

分布式管理系統是建立在網絡基礎之上的多臺計算機的應用系統，所以，為了防止由于各種病毒的侵入、學生的非法操作和計算機硬件損壞等因素對系統數據的破壞，系統設計了本地備份和遠程備份兩種備份方案，以確保系統能正常運行.

2.1.3與校園一卡通的對接

我校數字化校園的平臺—校園網已運行使用，校園一卡通也在教務處、食堂、圖書館等部門廣泛使用.如何將計算機實驗室的分布式系統與一卡通系統對接呢？對接方式有兩種，一種是緊耦合方式，就是兩個系統進行對接，系統只使用一個電子錢包，使用一卡通的卡內信息，學生的信息從卡上直接讀取，并在需要的情況下把產生的記錄傳送到一卡通中心的數據上；另一種是松耦合方式，就是兩個系統先不進行對接，系統有兩個獨立電子錢包，在計算機實驗室的刷卡機上刷卡只使用一卡通的卡號信息.具體使用哪種耦合方式再根據具體情況做出選擇.

2.2分布式數字化實驗室管理系統的優點和缺點

2.2.1分布式計算機數字化實驗室管理系統的使用，使實驗室的管理開啟了數字化模式，在規范實驗室管理和提高實驗室的效率方面的優點是毋庸置疑的.分布式管理系統是建立在網絡基礎上的多臺計算機協作運行的管理系統，因為多臺計算機相互協作完成一個共同任務這樣就加快了系統的處理速度，簡化了主機的邏輯結構；多臺計算機間可以隨時交換信息，實現數據和資源共享；成本低，易于維護，可以逐步實現實驗室的自動管理與無人職守；由于后臺系統與服務器端是采用分布聯接方式，而學生端與服務器端連接，所以系統能支持多達10萬臺遠程計算機的實時連接及實時的后臺數據處理，以便于管理的實驗室數量和計算機數量根據需求隨時進行擴充.

2.2.2盡管分布式管理系統有許多優點，但也存在一些缺點.首先，由于分布式管理系統是基于經典的C/S模式，即將分布式應用分解為客戶和服務器兩大部分，服務器只有在接到客戶的請求后方能提供服務；第二個潛在的問題是通信網絡，因為系統是基于網絡平臺之上的，那么網絡的信息丟失或飽和都將會抵消我們通過建立分布式系統所獲得的大部分優勢；第三是安全問題，數據易于共享是具有兩面性的，由于在分布式管理系統中，整個系統中的數據都可以方便地存取，所以系統的安全性問題成為我們經常要考慮大問題.

3將Agent技術應用于分布式數字化管理系統中

Agent技術是一種處于一定環境下包裝的計算機系統，為實現設計目的，能在該環境下靈活的，自主的活動.在分布計算領域，通常把在分布式系統中持續自主發揮作用的活著的計算實體稱為A-gent.它能夠有效地緩解順序的、集中的控制對系統的約束，以一種并發的、非集中的方式來尋求問題的解決.基于Agent技術的分布式系統使人們跳出了C/S系統的局限，適應了應用需求的發展.在分布式計算機數字化實驗室管理系統中加入Agent技術，開啟了新的計算機數字化實驗室管理系統模式，在這種新的模式中，Agent既是系統的基本構成單位，又是系統中獨立運行的實體.這種模式不僅可以占用更少的網絡，還可以縮短網絡連接的時間，減少網絡阻塞的發生，使系統更加安全和可靠，以便更好地對計算機實驗室進行管理；而且由于Agent具有交互性和主動性，查找信息和遠程交流更加方便快捷，提高了實驗室的管理效率，保證了實驗室分配的準確性，還降低了人工干預的費用.

3.1系統平臺模式

基于Agent的分布式計算機實驗室管理系統在傳統的C/S（客戶/服務器）構架上增加了一個s（分服務器）層，服務器層之間使用Agent層，即C/s/A/S（客戶端/分服務器/Agent/總服務器）模式，這種模式與傳統模式相比，占用客戶端的資源很少，要求客戶端條件比較低.即使網絡出現故障斷開，學生端只要與本實驗室的服務器連接就可以繼續進行刷卡，等網絡重新連接上之后，實驗室服務器上的記錄即可傳到總服務器上.這種模式降低了系統對網絡的依賴性，并且允許間斷式的連接，提高了網絡的利用率.

3.2分服務器層的實現

分服務器層在系統里相當于一個“橋梁”，起著連接作用，上面連接總服務器，下面連接客戶端，并為客戶端提供服務.分服務器層使用一個ClientSocket組件即TclientSocket類與總服務器相連接，并且使用ServerSocket組件即TserverSocket類給客戶端提供服務.如果需要向總服務器發出請求數據時，由ClientSocket組件申請與總服務器建立連接，并把總服務器反饋回來的信息進行相應處理后存入分服務器層數據庫中，供以后使用.ServerSocket組件一直進行網絡監聽，當某個客戶端發送過來數據時，它接收數據并進行相應處理后，把處理結果送還給這個客戶端.

3.3數據庫結構設計

在任何一個管理系統中，數據庫都是系統的核心.在基于Agent技術的數字化實驗室管理系統中，總心服務器、各實驗室服務器、客戶端都得圍繞著數據庫來運行.由于數據庫的數據存儲量大、訪問的用戶數目多.所以對數據的安全性和一致性要求比較高，對訪問速度的要求也比較高.在基于Agent技術的數字化實驗室管理系統中采用SQLServer組建后臺數據庫，并使用ODBC驅動程序將各種數據庫程序互相連接，以保證用統一的方式處理所有的數據庫.計算機實驗室的數字化管理是實現數字化校園的重要組成部分，隨著我校教學改革工作的深入，計算機公共課和專業課的上課與實驗、老師的科研、學生的創新項目設計都在計算機實驗室里進行，計算機實驗室的作用越來越重要，數字化管理的實現也迫在眉睫.我們將不斷地探索和完善計算機實驗室的管理模式，早日實現計算機實驗室的數字化管理.

參考文獻：

〔1〕李亞娟，王剛，熊玉明.基于分布式的機房管理系統設計與實現[J].微計算機信息,2011（10）：93-95.

〔2〕歐陽.機房管理數字佛手創新研究與實現[J].實驗技術與管理,2008（5）.

〔3〕李亞娟.分布式計算機基礎實驗機房管理系統設計[J].現代電子技術,2012（35）：37-39.

〔4〕睢丹.基于Agent分布式機房管理系統的設計與實現[D].華東師范大學,2007.

〔5〕李萍萍，霍曉鋼.改進Agent算法在機房數字管理中的應用研究[J].科技通報,2014（1）：127-130.

第3篇：分布式系統設計與應用范文

關鍵詞:城市軌道交通；變電所；綜合自動化系統

Abstract: at present, with the rapid development of urbanization, urban public transportation network as an important part of urban rail traffic network construction is also in fast development. This paper analyzes the urban rail traffic substation integrated automation of the definition, system structure and basic function.

Keywords: urban rail traffic; Substation; Integrated automation system

中圖分類號：TM63文獻標識碼：A文章編號：

前言

隨著社會的發展,城市人口日益集聚、土地資源日益緊缺、環境保護日益重要。近年來，城市軌道交通建設進入了蓬勃發展期,變電所綜合自動化在城市軌道交通領域的應用有了很大發展。本文研究了城市軌道交通變電所綜合自動化系統的結構和功能。

1 變電所綜合自動化系統的定義

變電所綜合自動化系統是將變電所的二次設備經過功能組合與優化設計，利用先進的計算機技術、現代電子技術、通信技術和信號處理技術，實現對變電所設備測量、監控和微機保護以及與調度控制中心通信等綜合性的自動化功能。

2 變電所綜合自動化系統的結構

變電所綜合自動化系統的發展過程與集成電路技術、微機技術、通訊技術和網絡技術密切相關。隨著科技的不斷發展，綜合自動化系統的體系不斷完善，功能和性能也不斷提高。從發展過程來看，典型的結構主要有：集中式結構、分布式結構、分層分布式結構等幾種結構類型。

1.1 集中式系統結構

集中式系統一般采用功能較強的計算機并擴展其I／O 接口，集中采集變電所模擬量和數字量等信息，集中進行計算和處理，分別完成微機測量、微機保護和自動控制等功能。由前置機完成數據輸入輸出、測量、保護及控制等功能，后臺機完成數據處理、顯示、打印及遠方通訊等功能。

集中式系統結構對計算機的性能要求較高，系統可擴展及可維護性較差，目前已基本被新的模式取代。

1.2 分布式系統結構

分布式系統是將按功能分布的多臺計算機連接到能共享資源的網絡上實現分布式處理。其結構的最大特點是采用主、從CPU協同工作，各功能模塊之間采用網絡技術或串行方式實現數據通信，將變電所綜合自動化系統的功能分散給多臺計算機來完成。

分布式系統結構提高了處理并行事件的能力，解決了數據傳輸的瓶頸問題，提高了系統的實時性。該結構方便系統擴展和維護，局部故障不影響其他模塊正常運行。自問世以來，顯示出強大的生命力，但目前還存在抗電磁干擾、信息傳輸途徑及可靠性保證方面的問題。

1.3 分層分布式系統結構

分層分布式系統從邏輯上將變電所自動化系統劃分為變電所層和間隔層，采用面向電氣一次設備或電氣間隔設備進行設計。間隔層中數據采集、控制單元和保護單元就地分散安裝在開關柜上或其他一次設備附近，相互間通過通信網絡互聯，并與所級測控主機通信。

分層分布式系統集中了分布式的全部優點，具體很好的擴展性和維護性。此外，該系統結構較分布式系統結構減少了二次設備及二次電纜，節省了工程投資。

2.變電所綜合自動化系統功能分析

2.1 微機保護

微機保護是綜合自動化系統的關鍵環節，它的功能和可靠性如何，在很大程度上影響了整個系統的性能，因此設計時必須給予足夠的重視。微機保護的各保護單元，除了具有獨立、完整的保護功能外，還必須具有：①保護裝置必須滿足快速性、選擇性、靈敏性和可靠性的要求，其工作不受監控系統和其他子系統的影響。②故障記錄功能。當被保護對象發生故障時，能自動記錄保護動作前后有關的故障信息，包括短路電流、故障發生時間等，以利于分析故障。③具有與統一時鐘對時功能，以便準確記錄發生故障和保護動作的時間。④存儲多種保護整定值功能。⑤授權修改保護整定值功能。對保護整定值的檢查與修改要直觀、方便、可靠，同時為了加強對定值的管理，修改定值要校對密碼，以及記錄修改定值者的密碼。⑥保護管理機功能。保護管理機把保護系統與監控系統聯系起來，負責管理和監視保護系統中各保護單元的工作狀態，并下達由監控系統發來的整定值修改等信息；⑦通信功能。由保護管理機或通信控制器與各保護單元通信，各保護單元必須設置有通信接口，便于與保護管理機等連接。⑧故障自診斷、自閉鎖和自恢復功能。每個保護單元應有完善的故障自診斷功能，發現內部有故障，能自動報警，并能指明故障部位，以利于查找故障和縮短維修時間，對于關鍵部位的故障，能自動閉鎖保護出口。

2.2控制和操作閉鎖

操作人員可通過CRT屏幕對斷路器、電動隔離開關投切進行遠方操作。為了防止系統故障時無法操作被控設備，在系統設計時應保留人工就地控制方式。操作閉鎖應具有以下功能：根據實時狀態信息，自動實現斷路器、開關的操作閉鎖功能；操作出口應具有同時操作閉鎖功能；操作出口應具有跳合閉鎖功能。

2.3數據處理和記錄

數據的形成和存儲是數據處理的主要內容，它包括上一級調度中心，變電設備管理和保護專業要求的數據，主要有：斷路器動作次數；斷路器切除故障時截斷容量；母線電壓定時記錄的最大、最小值及其時間每天的峰谷值及其時間；獨立負荷每天的峰谷值及其時間；控制操作及修改整定值的記錄。

2.記錄和故障錄波

事件記錄包含保護動作序列記錄、開關跳合閘記錄，其分辨率一般在1-10ms 之間，以滿足不同電壓等級的要求。變電所故障錄波可根據需要采用兩種方式實現，一種是集中配置專用故障錄波器，并能與監控系統通信。另一種是分散型，即由微機保護裝置兼作記錄及測距計算，再將數字化的波型及測距結果送監控系統存儲和分析。

2.5數據濾波處理功能

現場數據通過所內網絡傳至所內控制屏,經數據過濾及處理后接入車站綜合監控屏、經光纖上傳數據至中央監控系統。其中干擾問題可能由多種原因引起,在設計時要根據應用場所分析可能出現的干擾,有目的地設計抗干擾電路，選擇合適的濾波處理。如采用了遞推平均濾波法、中位值平均濾波法來處理電力數據,以提高數據的有效性。

2.6 與遠方控制中心的通信功能

在常規遠動‘四遙’的基礎上增加了遠方修改整定保護定值、故障錄波與測距信號的遠傳功能，其信息量大于傳統的遠動系統。根據現場的要求，系統應具有通信通道的備用及切換功能，保證通信的可靠性。

2.7 系統的自診斷功能

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

結束語

第4篇：分布式系統設計與應用范文

在網絡信息技術的不斷發展下，分布式軟件系統應用日益廣泛。分布式系統設計架構設計使用兩層C/S架構模式和三層B/S架構模式，可以用于進行數據的管理和用戶登錄使用。本文以分布式系統管理為基礎，對分布式軟件工程架構的實現進行了分析和探討。

關鍵詞:

現代分布式軟件；工程架構；C/S架構；B/S架構

隨著數據庫技術、計算機技術和互聯網技術的不斷發展，分布式軟件系統的應用也日益廣泛。分布式系統通過對軟件工程開發理論和成熟的IT開發設計技術進行應用，可以實現自動化的管理。近年來，管理軟件系統發展越來越快，軟件的功能也日益增加，為了可以保證軟件的可擴展性和可靠性，需要建立一個良好的分布式管理系統。當前，軟件體系架構還沒有提出一個明確的概念，軟件體系結構所面對的研究對象也有所不同。因此，可以參考軟件功能定義的不同，對軟件系統架構之間的交互性、交互模式等進行約束。本文重點對三層B/S體系架構模式和C/S體系架構的原理進行了分析，并對其作用進行了探討，分析了系統架構的優勢和劣勢。

1研究背景和研究意義

1.1研究背景

在企業生產經營過程中，工時管理是非常重要的一項基礎性工作，可以為企業的生產計劃、生產組織、確定產品價格、核算成本等工作內容提供參考依據。工時管理質量直接的對公司的經濟效益以及產品的成本造成了比較大的影響，做好管理工作可以提升企業的生產效率，降低企業的生產成本。所以工時管理是非常重要的。在信息化管理的今天，企業為了提高管理效率，需要積極的開發管理軟件，并積極實行數字化管理。由于不同應用軟件的開發環境存在差異性，例如編程語言不同、開發平臺不同、應用系統使用的設計模式不同等。這些差異性導致應用軟件底層數據也存在差異，數據模式、數據操作和數據結構存在異構性。在對企業流程進行動態性管理時，為了適應社會的發展，需要不斷的進行改革。例如企業發展過程中有可能需要收購或兼并一些小企業，或者需要進行拆分后對業績進行提升。在企業對這些數據進行整合時，需要隨時對企業的原有業務進行調整。同時企業需要調整市場業務或者引入新技術時，為了滿足新的需求，企業需要變更一些業務。由于企業的合作關系會隨著市場的變化而產生變化，企業之間的合作關系也會產生一定的變化，為了適應這些變化，需要動態化的進行調整。企業業務數據的共享性實質上指的是業務數據的共享和交互，即從外界獲取所需的數據以及向數據傳送出去。因為信息化建設會使用企業外部和內部信息存在信息孤島，對企業信息化軟件的利用和信息共享造成影響。所以，在開發軟件時需要對各種共享問題進行綜合考慮。在進行企業應用軟件開發時，為了可以更好的適應企業業務環境，需要保證應用軟件的靈活性、動態性和高效性。首先，要結合企業的業務流程開發企業應用軟件，并分解復雜的業務流程，使其成為獨立的子流程，在實際應用時，可以根據具體的情況靈活的對這些服務進行組合。此外，企業因為合作伙伴、政策、客戶變化等需要對業務流程進行改變時，為了可以適應市場業務環境的變化，要求企業軟件可以支持組建松散組合。這樣一來，企業軟件的開發對開發人員來說無疑是一個非常大的挑戰。在這種情況下進行軟件開發時，不單是為了可以達到企業業務發展需求，同時還要保證系統的高效性、可靠性和共享性。為了可以滿足上述要求，需要從技術的角度做好架構。從目前軟件發展情況來看，軟件架構構建已經經歷了面向對象、面向過程、面向構件幾個階段，其中面向對象只可以支持同種語言，面向過程不適用于開發大軟件系統。面向構件雖然可以做到構件二進制級別共享，不過應用平臺有一定的局限性。所以，一種面向服務體系的結構被提出，通過應用這種服務體系可以提高業務軟件的靈活性。此外，在數據庫部署過程中使用分布式部署的方式可以利用數據庫管理器對劃分開的獨立數據庫進行控制，實現數據的高效訪問。另外，利用通用接口可以實現兩個系統數據的集成和共享。本文重點從分布式軟件角度對軟件工程進行架構，確保其可以達到企業的發展要求。

1.2探究現代分布式軟件工程架構的意義

本次研究需要解決的問題為當前工時軟件需要重點解決的問題，研究的意義主要由下述幾個方面的的內容：（1）在工時軟件平臺中引入分布式技術，探索基于架構的軟件平臺，對工時軟件平臺的架構模型進行完善，并為設計提供新思路、新方案[2]。（2）提供一個可以滿足企業變化要求的方案，提升系統的靈活性。使企業工時軟件可以更高效、更快速的達到業務企業的業務需求。（3）進行分布式數據庫的部署和設計可以提升軟件數據信息的處理速度，對任務進行均衡的分攤。（4）利用底層接口包可以對系統數據實現信息集成和數據共享，保證接口的靈活性，便于開發者進行開發和使用。

2C/S架構介紹

在分布式管理系統發展初期，C/S體積架構是一種常用的系統架構，主要包括系統服務器端和系統客戶端，其中服務段是系統的的核心，主要有應用服務器、Web服務器和數據庫服務器進行溝通，可以對用戶發出的邏輯業務請求進行解析，并將收到的服務請求發送至數據庫服務器和應用服務器，進而降低數據的處理效果和反饋響應結果。客戶端為用戶提供系統操作界面，登錄操作系統后可以相系統發起邏輯業務請求。因為目前很多用戶利用的硬件配置均比較高，有助于提升服務器對邏輯業務的處理能力，緩解用戶解決服務器壓力，使服務器系統的通信需求降低，進而降低系統的開銷成本。所以，當前大部分的分布式系統軟件都是使用兩層C/S系統架構。利用C/S架構可以在局域網環境中使用，使用響應時間比較短、帶寬比較高、處理效率良好的通信傳輸方式。雖然C/S架構適用范圍比較廣泛，而且優點也非常多。但是隨著互聯網技術的不斷發展，政府單位的工作人員經常需要出差，在需要進入到系統時，如果不安裝客戶端則無法使用，而且隨著系統功能日益完善，使用系統的用戶會越來越多。所以，不適合在C/S體系中進行使用，在實際應用過程中，需要引入更加先進的B/S架構。

3B/S架構介紹

在時代的不斷發展下，網絡用戶數量日益增多，需要使用到的程序也日益增多，為了滿足使用要求，需要引入更加先進的系統架構。通過利用先進的架構可以把系統集成起來，然后利用瀏覽器直接訪問系統，不需要在設備上安裝客戶端程序，從而可以滿足各個層次的用戶使用要求。為了可以使上述問題得到解決，計算機行業的專家經過研究后提出了B/S體系架構模式，此架構模式主要包括Web服務器、瀏覽器、數據庫服務器等。其中Web服務器又叫做邏輯業務處理層、瀏覽器有叫做表示層、數據庫服務器又叫做數據庫處理層。各層的功能如下：（1）邏輯業務處理層。在B/S體系架構中，邏輯業務處理層指的是表示層和數據處理層之間的一層，利用該層可以封裝系統應用模型，并為數據表示層和處理層提供數據庫鏈接服務，可以根據用戶發出的請求，鏈接系統服務器端的數據庫，然后將得到的處理結果返回至用戶瀏覽器。（2）表示層。表示層指的是分布式系統和用戶的交互接口，在為用戶提供輸入輸出服務時可以通過具有良好友好性的圖形實現。在實際操作過程中，用戶主要利用瀏覽器來進行操作。并利用表示層將用戶填入的信息發送到邏輯業務數據處理層，邏輯業務處理層在收到客戶請求時會立即做出相應，并在瀏覽器中將得到的反饋結果輸出。（3）數據處理層。在B/S模型中，數據處理層是模型的最底層，主要負責數據的維護、數據的修改、數據的定義等，并且可以及時處理和回復接收到的瀏覽器請求數據。當前在分布式應用系統中B/S體系架構是一種常用的架構技術，在該架構中應用分布式管理系統時，用戶不需要按照客戶端應用程序，只需要將服務器地址輸入到IE瀏覽器中就可以登錄到系統中進行操作。但是隨著云計算技術和集成移動計算計技術應用的越來越廣泛，如果只是使用B/S系統架構是達不到系統要求的。所以，在未來分布式系統架構會朝著B/S、C/S混合架構的模式發展，可以顯著提升管理系統的響應性能，從云計算角度對分布式透明云計算架構進行研究，有助于分布式系統的進一步推廣和應用。

4結束語

綜上所述，在計算機軟件技術不斷發展過程中，軟件技術得到了快速發展，尤其是面向云計算、面向對象的軟件開發和分布式技術的應用，使軟件的復雜性得到了提升，而且應用好的軟件系統架構可以使軟件系統服務性能顯著提升，使軟件應用得到進一步的改進。

參考文獻：

[1]張曉梅,周莎莉,王秋生,等.基于C/S-B/S混合架構的道路施工實驗室網絡管理系統[J].工業計量,2010(6):12-15.

[2]林凡森.基于B/S體系架構的分布式管理系統應用設計[J].才智,2014(12).

[3]姚麗華,于廣州.三層B/S架構在分布式管理系統中的應用[J].信息通信,2013(4).

[4]張淑榮,蘇兵.05與曰S兩種軟件體系結構[J].電腦學習,201q6:126一127.

第5篇：分布式系統設計與應用范文

關鍵詞：GIS WebGlS 校園地理信息系統

中圖分類號：TP393

文獻標識碼：A 文章編號：1002-2422(2007)06-0020-02

1　基于WebService的WebGIS

WebService可以理解為一個由其它的應用程序通過Intemet調用的軟件組件。特點有(1)通過標準的Web協議(如SOAP協議)，WebService向Web用戶提供各種功能；(2)通過使用Web服務描述語言(WSDL)文檔的XML文檔，Websetrice能夠詳細地說明接口，使用戶能輕易創建客戶端應用程序：(3)通過統一描述、發現和集成協議(UDDI)，WebService可以進行注冊，使潛在用戶能夠輕易找到這些服務。

2　構建基于Web服務的分布式WebGIS應用系統，

利用開發工具(如Visual 等)直接從底層開發GIS Web服務，也可以將已有的GIS應用系統或GIS組件封裝成Web服務，以供其它需要的應用系統通過互聯網來調用。

2.1　構建WebGIS結構體系

將基于Web服務的分布式WebGIS應用系統設計為由數據層、業務邏輯層和客戶端組成的三層結構體系。客戶端是唯一與最終用戶的交互點，通過超文本傳輸協議，將服務請求及相關參數提交給Web服務器，以便與業務邏輯層進行交互，并把響應結果呈現給用戶，同時完成基本的操作。業務邏輯層是分布式WebGIS應用系統的核心。它負責處理客戶端的應用請求和聯系數據層，以完成業務邏輯的計算任務，并將處理結果返回給客戶端。應用服務器解析請求并執行應用邏輯，加載和調用相應的本地組件和遠程GIS Web服務協同進行業務處理，并將處理結果通過Web服務器返回給客戶端。在應用中，調用的Web服務接口保持不變，應用系統就無需考慮Web服務是否改變。

2.2　構建GIS解決方案

GIS WebService適用于理解XML和通過標準的網絡(LAN／WANAntemet)連接的任何應用程序，包括桌面應用程序。利用GIS WebService的應用程序可以輕易實現GIS的功能而不需要在本地安裝GIS工具以及空間數據。以此構建低成本、可伸縮并與其它系統(如DBMS、Web Server等)無縫集成的分布式GIS系統，此系統具有松散耦合的架構，以此提供了構建復雜的分布式系統的解決方案。

2.3　構建GIS WebService空間數據

用WebService在傳輸數據時，默認是利用XML文本的形式傳輸數據的，這就大大增加了傳輸的數據量。如果網絡帶寬不夠就會影響系統的性能，這時可以采用在XML中嵌入二進制數據的方法。

第6篇：分布式系統設計與應用范文

與分布式賬本技術（如Hyperledger Fabric或R3 Corda）相比，以太坊區塊鏈保持了相似性但也有差異。在對區塊鏈和分布式賬本技術平臺及其帶給企業的價值進行合理評估時，對其核心功能和特性進行系統梳理是很有必要的。 由于區塊鏈源于密碼學和數據配置原則，某些功能在協同數據庫系統中已經得到了很好的應用，而其他一些功能只有在真正的區塊鏈技術中才能實現。

在本文中，我們將評估面向企業平臺（包括Ethereum，Hyperledger Fabric和R3 Corda）的基礎業務功能，包括軟件如何獲取其影響以及整個系統是如何整體優化的，無論它是通過傳統的分布式系統還是通過區塊鏈系統。

特別是，我們將重點關注三個關鍵功能：

數據協調 – 系統中的信息和信任是如何更好地在利益相關者之間分發和分配；

加密經濟內部激勵層 – 系統機制如何構建，以便不同的利益相關者和用戶基于經濟激勵來確保系統的有效運行，例如博弈論和機制設計；

數字資產整合 – 系統如何融入數字商品經濟，也就是所謂的代幣經濟學。

區塊鏈的主要目標：企業想通過這項技術實現什么目標？

像Ethereum這樣的區塊鏈與其他分布式帳本技術類似，有著相似的目標。然而想知道企業希望利用區塊鏈技術實現什么樣的目標很難，就像20世紀90年代的互聯網剛剛誕生時一樣，當時企業也不知道如何使用這種強大的工具。與現在的情況類似，目前我們都知道區塊鏈技術能夠實現很多功能，但如何將這些功能架構到商業業務邏輯上還需要進一步了解和評估其底層功能。

有三個主要的評估維度：數據的處理和協調，可信及不可變的記錄以及資產的數字化。

這三大維度足以涵蓋區塊鏈的主要用途，同時允許將這些功能進一步外推到其他商業業務場景中。通過這三個方面的討論，可以揭示實體企業使用該技術的背后邏輯。

有效處理及協調信息

如果以改進分布式系統設計或數據庫協調性作為唯一目的，那么區塊鏈不一定是必需的。在傳統的宣傳上，區塊鏈是基于技術促進平臺中數據傳輸，達到更好的數據協調和分布式共識機制。

雖然有用，但這些所需功能特性的重要部分也可通過更好協調中央數據庫或分布式系統設計進行優化。在評估當中，有必要確定平臺和協議試圖優化現有數據協調功能與實施新的區塊鏈功能程度。區塊鏈不僅只適用于更高級的數據協調。

產品和交易記錄的不可變/可信記錄

關于為什么我們需要區塊鏈的原始論文圍繞著“數字化信任”的概念展開。如ConsenSys的Andrew Keys所說“互聯網導致信息數字化，而區塊鏈導致信任和協議的數字化。”

這個論點體現了區塊鏈希望實現的精神，同時為我們的社會及商業提供了另一條路。額外的變量將是價值的數字化。當信任價值被錨定到系統時，某些聯盟結構和激勵機制將影響和激勵系統內的正確行為，從而形成強大的平臺。

在設計一個系統時，不可更改（不變性）常常被用作信任的同義詞，即因為系統是不可變的，所以人們相信系統不變性機制能確保做壞事會受到懲罰。在我們的平臺協議評估中，重要的是要評估可信系統實施背后的機制，以確保商業模式機制（通過密碼經濟學進一步探索）會對平臺用戶有益。

資產數字化

商品和資產的數字化被視為大多數區塊鏈或分布式賬本技術的主要目標。如果企業正在嘗試資產數字化，分布式賬本的數據庫協調能夠提供一些功能，但更應該考慮這些數字產品的可用性。

由于數據庫協調實質上是集中運行或通過傳統軟件模式分布在一個或多個交易小組之間，因此數字化水平可能會受限于數字化平臺提供的自由度。

雖然數字化商品的概念聽起來像一個簡單的過程，但圍繞房地產，甚至人類注意力及電力等商品如何數字化在經濟激勵動力和經濟推理的不同方面，我們要重新考慮，哪個平臺負責數字化，哪個供應商平臺在哪種情況下出現“供應商鎖定”程度以及對哪個管理平臺的依賴。

記錄和注冊管理機構（如權證系統和供應鏈）也可以通過分布式賬本系統實現，但如果依賴封閉的專有系統，數字資產與經濟激勵層的互動水平相當有限，并且在擴散到數字生態系統或市場時會嚴重受阻。利用開放市場提供的自由市場系統對于在不斷發展的數字生態系統中起促進作用。

評估數據協調特性

數據庫協調：特征

當深入分析了這些平臺的功能特性時，如不可變性，安全性，可擴展性，可管理性和性能，但通過了解構建體系結構的基礎，可以了解更多內容。

在分布式系統中進行數據協調，已經有許多工具了。其中重要的例子就是Hadoop 及其生態系統集成的Spark，Hive和Zookeeper等工具。對這些產品的依賴顯示了分布式系統工具和協議的大量集成。

進一步的相似性可以在協議中顯示出來，例如Tendermint，BPFT共識引擎被設計為具有與Apache Zookeeper等工具類似的功能。在內部，也有研究沿著事件排序數據庫的方向發展，可以從協調的數據共享系統中復制所需的多種功能。

通過評估Apache Kafka及數據流服務如何在企業環境中實現高水平吞吐量，我們可以根據對這些數據庫協調和優化的不同級別的依賴關系區分區塊鏈和分布式分類賬之間的功能差異。

包括Plasma在內的以太坊實現正在利用像MapReduce這樣的工具來增強UTXO和基于賬戶的模型之上的某些映射功能，同時也將組件減少到Merkle證明中，盡管協議的基礎層依然依賴以太坊區塊鏈。通過了解這些細節，可以進一步了解如何最好地評估這些軟件平臺的技術特性。

數據協調：平臺比較

（1）IBM Fabric

通過深入了解Fabric體系結構，該平臺創建了一個復雜的開發環境，專注于軟件體系結構的詳細配置實現出色的吞吐量，從而在分布式節點環境中實現最佳性能。客戶端和分布式背書節點網絡之間的鏈碼的移動，以及滿足認可政策的交易機制和收據傳輸在封閉系統中是有效的。

而在專用信道內傳播交易的Gossip 協議允許協調大型數據集。雖然基礎設施強大且有能力，但在思考如何設計架構以允許多邊協調結構的過程中，要考慮最終可能存在一個難以管理的網絡涉及的因素。

圖2：Hyperledger Fabric架構

該圖展示了Fabric的一些架構配置以及組件如何組織到為高級信息處理和最大交易吞吐量而設計的系統中。

主要思想是渠道提供了在平臺內移動交易的機會。在查看體系結構時，OSN（ordering service nodes）的功能用于記錄Apache Kafka交易排序的功能。在數據流生態系統中，Kafka是一個功能強大的工具，具有將各種交易排序附加到單獨的Kafka集群并最終分區的功能。

這種設置中，數據能夠分布在集群中以形成分布式存儲平臺，該分布式存儲平臺可以記錄數據結構，影射在區塊上或有時記錄在“狀態”的結構定義內被稱為“塊”或Blob的數據結構，價值儲存配置。在此軟件框架中承認的是，該生態系統中的所有參與者和數據結構都是本地的，因為它們主要與該軟件生態系統中的其他用戶一起工作。

圖3：Apache Kafka

盡管應該認識到哈希的配置并不遵循與來自比特幣或以太坊的區塊鏈系統相關聯的原始架構設計，但實際上Fabric采用了分布式帳本的子結構來部署某些哈希鏈接的數據存儲。

雖然數據blob被批量處理并經歷交付事件以最終創建交易的散列鏈接，但必須了解，此過程不一定會將數據轉換為系統狀態的修改。相反，這些塊的配置方式是將信息存儲在具有不同散列實例的數據庫類型結構中。

在Fabric生態系統中，交付事件稱為塊，而鏈代碼通過部署事件最終將數據保護在排序服務結構的鏈接部分中。該系統的數據結構和模塊的配置能夠允許分布式數據庫體系結構預期的交易吞吐量，盡管應該承認，資產代碼協調仍然是一個尚未完全解決的挑戰，作為資產和價值的Fabric生態系統不一定具有可以在賬簿中進行協調的數字表達。

（2）R3 Corda

R3 Corda聲稱不建立區塊鏈的環境之上，而是一個分布式的數據庫，利用各種形式的結構重新配置來構建，它主要由銀行和其他機構用于其流程的系統。該平臺大量借鑒了比特幣交易中使用的UTXO模型，其中狀態由一系列輸入和輸出定義，并且輸入的不同重新配置可以決定輸出的狀態。

R3 Corda架構框架依賴于被稱為公證的子模塊的節點結構，該架構有助于保持其他平臺中驗證器結構的網絡有效性，該結構有抽象共識功能。節點由附加在數據結構中的關系數據庫組成，允許使用SQL進行查詢。交易通信中受制于子協議。

這些流程與IBM Fabric中看到的渠道體系結構相當，只有與交易相關的各方才能訪問信息。類經過轉換，變成稱為Fibers或協同例程的狀態機。該體系結構與子流進行通信，并與在平臺范圍內具有預定義功能的流庫進行交互。此外，Corda內還有一個自包含的身份層，允許在整個網絡中進行不同程度的訪問控制。

R3 Corda公開聲明不打算成為區塊鏈，因為考慮到將分布式數據庫的概念重新配置到分布式數據庫確實非常依賴傳統數據庫系統。雖然系統圍繞新型數據結構和分布式系統組織方式的不同構成進行架構，但該平臺確實具有數據分配的功能，并找到了各種優化數據分配系統功能的方法。

需要記住的是，由于系統僅限于特定架構范圍內的數據協調，因此，由于模塊化和互操作性未在原始設計中實施，所以已經犧牲了與實際區塊鏈系統的集成。

圖4：R3 Corda工作流程

（3）Ethereum

以太坊生態系統由私有鏈和公有鏈生態系統組合而成。公有鏈沒有在數據協調環境中描述的吞吐量和數據處理能力，因此不應根據這些能力進行評估。在評估以太坊的這一方面時，最有意義的是綜合以太坊私有鏈的網絡拓撲的不同細微差別。

以太坊黃皮書頒布了關于以太坊的規范以及代碼庫的技術細節。由于嚴格遵守此協議，以太坊的分支以及聯盟實施方案確實與原有的技術基礎相類似。事實上，無論是在工作證明（Proof of Work， PoW ），權威證明（Proof of Authority）或利益證明（Proof of Stake， PoS）實施方面，相同的規范都是連續的，因為協議被認為是相同的以太坊虛擬機（EVM）規范的后代。

改進的體系結構仍然指定與原始EVM對齊。像Quorum這樣的平臺的關鍵變化包括改變共識機制，修改全球根狀態以適應私有和公有狀態，Patricia Merkle嘗試以及處理私人交易的附加模塊。

該架構允許該軟件從原來的以太坊配置中維護系統和數據結構，同時通過改進實現更高的交易吞吐量。除了Quorum提供的改進的數據交易優化之外，通過諸如Plasma，Truebit和Cosmos等工具協調和集成公共以太坊環境的功能為協議提供了額外的可擴展性。

通過對Plasma等工具的技術評估以及在Casper中獲得一致意見的形式，數據庫管理工具（如MapReduce和Abstract Rewrite Systems）將在Ethereum中實施。在Plasma體系統中，MapReduce是匯集基于賬戶的系統的協調和多重設置的位圖 – UTXO承諾結構的組成部分。

通過結合防欺詐機制設計（Fraud-proof mechanism designs）和權益激勵結構（Fidelitybond incentive structures），利用根鏈，Plasma鏈和子鏈之間的相互作用，精心策劃的交易處理范例有助于滿足Block-withholding和Mass withdrawalsurfaces之間的動態。

它還允許使用來自Casper或Truebit等系統的機制來填充更多的加密經濟結構，以便根據空間中普遍存在的數據可用性問題鏡像擦除編碼中使用的概念。對于多連接體系結構，以太坊將能夠將分布式數據庫系統的數據庫協調和吞吐量功能與實際區塊鏈的公有鏈兼容功能相結合。

數據庫協調：結論

關于數據庫協調能力的一個可行結論是，由于依賴傳統數據庫和分布式系統軟件架構，IBM基于整體單一設計和大量資源密集型過程，構建了Fabric，IBM擁有卓越的數據庫管理工具集。

R3 Corda仍在進一步定義其功能，同時為銀行和金融機構提供多種協調服務，對比特幣協議中的細微差別進行私人重新配置。以太坊雖然設計用于公有鏈的兼容性，它沒有IBM Fabric的原始數據庫處理能力，但和Fabric相比，在企業案例中具有很好的可用性和可伸縮性。

遵循基于unix理念的模塊化設計，以太坊和互補客戶的私人實例可以作為構建大型系統的構件。與Ethereum相關的代碼庫旨在與Fabric等數據庫平臺的事務吞吐量功能相媲美，同時允許Corda和Fabric中不存在的功能，但互補關系也可跨平臺進行探索。主要的區分因素可能會從后續因素的評估中進一步闡明。

軟件平臺內的一個加密經濟子系統需要機制設計和博弈理論的各種配合，激勵系統內角色以最優方式行事，這既有利于他們自身的利益，也有利于整體生態系統。區塊鏈系統與分布式賬本數據庫系統的核心區分原則是能夠將機制設計作為一種經濟激勵層，確保適當信任和合作，使系統的行為方式有利于實現用戶分布式共識及安全。 這些依賴于“反向博弈論”設計的系統的主要目標是在一個子系統內創建一個主導策略，從而形成激勵的均衡結構，并進一步增強整個系統的整體完整性。

加密經濟機制設計實例

Plasma & Truebit

Plasma旨在為以太坊網絡帶來可擴展性和多鏈性。通過提供以太坊體系的多個區塊鏈可以相互連通的催化劑，Plasma可充當私有鏈和公有鏈網絡之間的溝通橋梁。進一步的分析可以看出，Plasma為Ethereum網絡提供了擴展性和可用性。

要了解Plasma的有效性，了解Plasma的設計機制很重要。大量的互操作性是通過所謂的Fraud proofs來實現。通過配置區塊鏈，基于MapReduce函數的計算及通過最小化信任來實現可伸縮性，以便即使是新派生的子區塊鏈仍然可以可靠地驗證交易。

圍繞Plasma設計了一種機制，以便在發現故障鏈時允許所謂的Mass Exists。這些與錯誤操作有關的情況與數據可用性的不一致性和阻止預扣攻擊(block withholding attacks)相關。通過允許關聯鏈的交替配置懲罰邪惡活動的機制，生態系統希望實現內聚均衡。

Plasma在Truebit平臺上實現相當多高密集的經濟激勵結構，旨在增加以太網網絡的離線計算能力。通過構建Truebit系統圍繞驗證博弈進行構建，在該驗證博弈中，整體共識機制的解算器可以被驗證者挑戰，驗證者如果識別出邪惡行為則獲得獎勵，這是一個系統內部加密經濟的“檢查和平衡”公平的行為策略。

由于Plasma通過TrueBit的影響致力于創建一個多連接互操作性網絡，系統的內部實施對于實現信息和共識保真度至關重要。

以太坊Casper權益證明

在以太坊通過實施Casper權益證明共識機制的過程中，也可以看到加密經濟激勵層的一個例子。盡管工作證明（POW）有自己的內在博弈理論激勵結構來防止參與者操控網絡，但是向權益證明過渡還有更多的內部結構來阻止參與者在遇到分叉時模凌兩可或試圖創建區塊鏈的其他實例。權益協議創建了一個拜占庭容錯環境（Byzantine Fault Tolerant，BFT）。在這個環境中，Ether將被綁定到共識機制中。這意味著，參與者在系統內將受到忠誠的約束。

如果攻擊者計劃在共識機制中模棱兩可或試圖控制，那么有關切入型算法“slasher algorithms”的各種協議將會破壞Ether所有者或攻擊者的權益，從而懲罰他們的惡意行為。在懲罰背后的機制設計中，Ether破壞的數量一直被編程為與攻擊者希望獲得的數量成正比，在這個數量中，攻擊者永遠不想妥協系統。

Cosmos and Tendermint

Cosmos也在建立一個依賴Tendermint共識機制的生態系統，該機制嚴重依賴于拜占庭容錯算法。該平臺依賴于與比特幣網絡中礦工類似的驗證器。驗證人擁有一個叫Atom的token，用于通過依賴綁定驗證器生成的信任的證據機制來保護網絡。

Cosmos生態系統中的參與者之間的相互作用也表明了一種博弈理論結構，即如果發現驗證者發現違反協議，驗證者可能會丟失其令牌（Token）或委托給他們的令牌。由于這個系統中的利益相關者的這種保稅存款設計，共識機制允許保護網絡的激勵機制。此安全設計允許應用程序區塊鏈接口（ABCI），區塊鏈間通信協議（IBC）以及Cosmos集線器和區域之間的不同交互功能正常運行。

R3 Corda和IBM Fabric

需要注意的一點是，R3 Corda和Hyperledger Fabric在其軟件體系結構中沒有這些加密經濟激勵層。由于軟件體系結構是基于分布式數據庫聚焦范例進行基礎設計的，因此它們最初不是為在整個框架中加入加密貨幣層而設計的。

由于軟件設計的內在差異，它們還沒有經過校準，無法參與那些與眾多區塊鏈具有互操作性和協調性的多鏈生態系統。由于系統結構的最大吞吐量考慮在內，基于這些系統的初始構建，忽略了包含區塊鏈（包括公共區塊鏈主網）的可互操作網絡拓撲的體系結構布局。

為什么加密經濟機制設計是必要的？

有人可能會問，為什么要把加密經濟基礎設施層架構在軟件上？因為存在于計算環境中的這種模型所創造的是一種不變的可信任的新層，而不依賴于中心化實體。

數十年來，我們一直在客戶端-服務器和數據庫中構建軟件。像IBM，Intel和Oracle這樣的公司在其初創及其后創的系統及子系統中完善了這個模型，而這些模型仍然在分布式系統以及新近的分布式賬本系統中使用。

盡管這些體系仍然集中在各個方面，無論是通過中心化實體還是cartel-like (卡特爾式) 的聯合體結構。這種聯盟結構為了確保系統的正常運行，激勵機制都是基于中心實體而不是真正的激勵結構。

圖6：客戶端服務器模型

去中心化系統為在軟件環境中達到某些目標提供了可行的替代方案。這種方案主要權衡是內部交易信任 vs 執行。由于大型中心系統的信任度更高，因此它被認為能夠更好地執行。盡管區塊鏈系統的特征，是在這個系統中信任和價值可以在不依賴大型中心實體的情況下合理配置。

在系統設計中倡導的一個思想是，為了優化系統，還需要對子系統進行次優化。這意味著系統的協調必須進行協調和架構，以便內部子系統在整個更大的生態系統中也具有利益及激勵，以進一步實現合作目標。

通過創建一個用于整體環境優化的加密經濟博弈理論，融合計算機科學和經濟模式，以創建數字經濟中的新軟件架構。

基于對數字經濟的這種愿景，應該認識到，使用私有鏈和公有鏈的組合互動，各層商業和商業關系超越傳統模式，創建一個可行的數字生態系統成為可能。

整合到區塊鏈token經濟體系中

為了調查的目的，有必要定義Token化的概念，它借鑒了這樣一個概念，即企業或實體能夠根據我們生態系統中目前存在的某些數字標準，創建各種形式的資產、商品和服務的可互換或不可互換的表現方式。

最初的token化設計會有各種各樣的故障和缺陷，Token經濟仍在發展，需要時間迭代才能進一步完善。盡管資產，金融產品，能源和注意力的Token化都是可行的商業模式，但它們實施的確切動態需要額外的功能和訪問層次，需要時間進行改進。

token化經濟需要博弈論機制設計和區塊鏈創新，隨著它們帶來重大發現和發展，最終促進token化經濟的成功。

正如Josh Stark關于數字經濟學的文章中所描述的那樣，評估表現出最強可用性跡象的Token，看看它是否構成了整體業務的經濟學和博弈論設計的必要組成部分。

如果企業可以對其生態系統的各個方面進行數字化或Token化，那么創建的產品線將以指數級擴展，超越了我們用來交換實物商品，金融資產，商品或技術服務的傳統方式。通過創建Token化資產可以實現數字媒體。一些重要的發展可以從新的生態系統發展而來。

在查看區塊鏈工具的生態系統時，顯然以太坊實際上是Token化經濟得以創建的基礎。如果Token化經濟模型能夠結合私有鏈，可擴展性解決方案和隱私工具（如ZK-Snarks）的功能，則數字資產的整體Token化將全面超越受內部激勵限制的傳統經濟模式。

實現區塊鏈的業務目標

為了實現區塊鏈的上述業務目標，我們必須評估需要提供服務的各個維度。在詳細介紹上述模型功能的圖表概述中，Ethereum能夠實現分布式數據庫協調方案，激勵層以及Token化，而R3 Corda和IBMFabric尚有一些功能未涉及。

我們針對現實世界不同的業務場景應用不同功能，以更好地理解平臺的功能。

圖7：功能摘要

信息的有效分配

從功能上講，從分布式系統的數據庫協調和利用角度來看，這些產品有著同樣相匹配的功能。 R3 Corda，IBM Fabric和企業版以太坊確實具有分布式信息分配功能，可以通過不同層次的訪問權限控制和聯盟配置管理來促進信息分配。雖然每個平臺的軟件架構配置都不相同，但每個平臺都可以執行有效的信息分配和協調所需的性能。

可信不可篡改的信息

在許多這些技術的背景下，不變性被視為信任的同義概念。在評估不變性特征時，必須了解的是，在利用基于Apache的數據流工具（如Kafka）的系統中，存在允許讀/寫數據訪問的固有功能。因此，由于在系統設計中進行了一些選擇，IBM Fabric的不變性方面受到一定限制。

對于R3 Corda基于UTXO模型的系統，不變性方面在整個系統范圍內保持不同。由于其系統的整體分布式賬本設計，它們已經建立了可在整個平臺上展示的某些信任方面。

在以太坊背景下建立起來的信任和不變性都是在基于Patricia Merkle Tries的公有鏈的子協議中。由于這種生態系統內核心軟件范例的保存以及與公有鏈的可連接性，以太坊區塊鏈和以太坊的相關派生能夠充分證實不變性。隨著資產數字化開始，這種不變性中獲得的信任終將增加生態系統的價值。

資產數字化

應該認識到，IBM Fabric名義上能夠創建數字資產的，因為資產的數字化實際是把產品注冊成數字格式。但是在Fabric上創建的數字化資產將只能在Fabric的系統上運行。就像如果你在某一電子郵件客戶端A上創建的郵箱只能夠與使用完全相同的電子郵件客戶端A的人進行通信，這與當前世界中存在多個電子郵件客戶端可以互相通信的不同。

R3 Corda也存在類似的不一致之處，因為R3的平臺用戶在與R3之外的其他平臺進行交互通信時會受到限制，從而導致供應商鎖定(vendorlock-in)。由于R3 Corda主要關注銀行客戶，而銀行需要獨立的銀行軟件。應該指出的是，該平臺的用戶將僅限于與僅使用R3 Corda的機構建立銀行業務關系，無法與不使用R3 Corda的生態系統伙伴進行無縫互接。

由于以太坊是一種類似于Web服務中的HTTP或TCP / IP的底層協議，因此不存在只面向以太坊的構建者“供應商鎖定”問題。通過以太坊區塊鏈的不同方面建立的信任關系能夠在全球資產數字化的新經濟體系內發揮作用。如果再參考電子郵件示例，以太坊協議可以被視為與IMAP或POP3類似的通用協議來訪問電子郵件。

以太坊和以太坊派生的協議可以充當區塊鏈基礎設施，公司可以建立數字資產。類似于每個公司在90年代后期能夠使用HTML創建網站，每家公司都能夠使用以太坊智能合約為其服務和產品創建數字經濟，這些合約可以創建token，可通過更廣泛的網絡訪問。

未來之路

為了構建一個足夠強大的平臺，可以與公共市場進行互動，該系統必須能夠滿足業務需求，以實現數據的高效處理、額外的信任分配層以及具備數字經濟資產的代表能力。顯然，這三個維度的目標都是通過不同的技術進步和技術配置來達到類似的目標。

在未來的道路上，我們必須考慮經濟商業模式在這個生態系統中的發展方向，顯然基于以太坊的平臺在融入數字經濟中具有優勢，盡管在某些數據交易中存在明顯的弱點，這正是IBM Fabric和R3 Corda的突出特點。

由于不同的區塊鏈和分布式賬本平臺被快速迭代使用，并且超越了我們當前技術時代已有功能，所以圍繞使用哪個平臺進行構建的決策將會嚴重依賴于我們的生態系統中的場景用例，可以看到不同的用例相互依賴。

本文并不試圖說明一個平臺總體上比另一個平臺更好，而是在于說明各有特色。以太坊具有的某些功能是Fabric和Corda這樣的分布式賬本所沒有的，但Fabric和Corda也有Ethereum目前不能達到的較高的性能。

為了真正實現現有系統所期望的交互和可擴展性的水平，必須構建和設計一個協議，并考慮到所有的交互，類似于互聯網最初設計的方式。以太坊作為協議，能夠充當基礎技術棧，為足夠廣泛的生態系統提供服務，可以涵蓋經濟環境中的必要因素，但請記住，該平臺目前尚不完整，并且還可能受益于之前DLT對手們固有的功能。

第7篇：分布式系統設計與應用范文

關鍵詞：TTE網絡 分布式 數據采集

中圖分類號：TP393 文獻標識碼：A 文章編號：1007-9416（2016）05-0000-00

1 引言

目前，數據采集系統一般使用集中采集方式，被測系統通過電纜連接到數據采集設備，數據采集設備采用商用總線（VME、CPCI）等通用總線設計。雖然這種設計方便，但是這種系統存在較大的缺陷，主要表現在以下幾個方面：一是系統同步性差，采集到的數據往往是不同時刻值的數據，無法準確評估在同一個時間剖面內被測系統的工作狀態；二是系統實時性不高；三是系統布線復雜，可擴展性差。

針對上述問題，本文提出了一種基于TTE網絡的分布式智能數據采集系統。解決了傳統以太網以事件為觸發機制而存在的不確定性，繼承了傳統以太網的優點，同時還具有高實時性、確定性、高可靠性等特點。

2 系統實現

2.1 系統構成

分布式智能數據采集系統采由一個主采集節點和若干個智能子節點組成，其組織原理如圖1所示。其中主采集節點是系統的控制核心，負責整個系統數據采集控制、數據存儲與傳輸、時鐘同步、系統管理等；智能子節點可以自主的完成規定的數據采集動作，實現數據的緩存，時間同步及采集數據上傳等功能。

分布式智能數據采集系統采用主采集節點統一授時，各個子節點在此授時的同步下完成數據采集動作，經理論分析和試驗驗證，系統的同步誤差小于1us。該系統可以為數據分析提供更加平滑的時間剖面，為分析被測系統在同一時刻下各個節點的狀態提供強有力的支撐。

2.2 主采集節點實現

主采集節點由主控單元、存儲單元及TTE接口協議單元組成。主控單元是系統的控制核心，對外接收數據采集方式配置并上傳系統工作狀態，對內控制采集系統的工作；存儲單元用于存儲采集到的數據，用于事后分析和處理。

主控單元接收上位機配置信息和控制指令，上傳系統工作狀態和關鍵數據。主控單元由ARM處理器、FPGA、電源系統等組成。ARM處理器完成主控單元事務處理工作。FPGA是控制的核心，數據采集系統的時間同步、數據接收、存儲等核心功能均由FPGA實現。存儲單元選用美光公司的NANDFLASH器件，設計容量可達64GB到512GB。

2.3 智能子節點實現

子節點實現具體的數據采集功能，周期的完成規定采集動作，并將采集數據通過光接口上傳到主采集節點。從功能上分為TTE接口協議單元和功能單元兩個部分。TTE接口協議單元實現同主采集節點的通訊，完成數據、狀態等信息的上傳和指令信息的接收；功能單元完成具體的數據采集，按類型可以分為總線數據采集、AD、開關量等。

3 結語

本文描述了一種分布式智能采集系統的設計，該系統具備實時性好、同步精度高等特點，經使用驗證，該系統工作穩定、可靠性高，可以應用于對數據采集要求較高的場合。

參考文獻

第8篇：分布式系統設計與應用范文

關鍵詞：CAN總線高速采集A／D轉換數據傳輸

在某大網架結構的建筑中，由于網架結構的特殊性及其所處地理位置在沿海臺風多發地帶，因此需要設計高速數據采集系統對網架結構的健康狀況進行實時監測，并對數據進行實時分析和評估。由于需要對網架上受力情況進行多點監測，考慮到硬件集中控制擴展能力差且在現場施工有較大的布線困難，因此本系統采用目前廣泛應用的分布式系統設計方案，將各個控制單元分布在現場各采集點上。為了實現分布式系統的監測與控制功能，需要建立良好的通訊方式，以完成系統主機與各智能單元之間的信息交換與通信。根據本數據采集系統的特點，其通信系統應具有良好的可靠性、適應性、可擴展性和簡單的連接方式，并能滿足長距離傳輸的需要。由于此數據采集系統節點數多(100路)、對信號傳輸速度要求高且誤碼率低，利用485總線搭建數據采集系統的傳統方式，其最大控制結點只能有32個，在超過lkm的布線結構中傳輸速度只有lOOkbps，且“數據碰撞”和“死鎖”等問題不易解決，因此采用485總線顯然達不到設計要求。

相對于傳統的485總線來講，控制器局域網CAN(ControllerAreaNetwork)作為現場總線的一種，以其分時多主、非破壞性總線仲裁和自動檢錯重發等靈活、可靠的通信技術解決了485總線現場調試困難、開發周期長等問題[1]。尤其在較為艱苦的安裝環境中，其高效的現場調試性能顯得尤為實用。作為一種分散式、數字化、雙向多點、具有高速率高可靠性特點的通信系統，CAN可以構建靈活的多主通訊機制，也可以建立主從式結構，而且這兩種方式下的硬件物理聯接完全相同。其自動進行數據編碼、CRC冗余校驗、出錯自動重發的功能保證了數據的準確率，某一節點嚴重出錯時能自動脫離總線保證了系統的穩定性，且其具有極強的帶負載能力，可驅動多達110個節點，可滿足本系統高速、精確、多負載的要求。

1采集卡硬件電路的設計

1．1CAN總線分布式系統結構設計

系統結構如圖1所示。本系統由上位監控PC機、CAN總線適配卡和控制單元三部分組成。上位監控PCs機采用IBM-PC兼容機，主要負責對系統數據的接收與管理、控制命令的發送以及各控制單元動態參數和設備狀態的實時顯示；CAN總線適配卡可以使PC機方便地連接到CAN總線上；控制單元以單片機為核心，主要負責對現場的環境參數和設備狀態進行監測，對采集來的數據進行打包處理并將處理過的數字信號通過CAN通信控制器SJA1000送入CAN總線。

1．2控制單元模塊設計及關鍵問題的解決

控制單元的主要功能是將現場采集的模擬信號轉換成數字信號，通過CPU處理后再由CAN總線控制器打包送上CAN總線以便上位機接收處理；接收上位機控制信號，實現現場控制的具體操作。具體需要解決的問題為：①CAN模塊設計；②A／D模塊設計。

1．2．1CAN模塊設計

控制單元以8位單片機AT89C51為核心，選用器件SJA1000作為CAN控制器，并選用芯片82C250和6N137作為CAN控制器接口和光耦隔離。硬件電路如圖2所示。

系統采用的CAN總線通信控制器SJA1000是PHILIPS公司生產的一種獨立式CAN器件，其原理框圖如圖3所示。它與CAN2．OB相兼容[1]，同時支持11位(BasicCAN模式)和29位(PeliCAN模式)識別碼。

圖2中AT89C51單片機的ALE、WR、RD端分別控制SJA1000的ALE／AS、WR、RD端，地址和數據線ADO～AD7由P0口分時復用實現。SJA1000的中斷請求信號INT在中斷允許且有中斷發生時，由高電來此跳變到低電平，所以INT和AT89C51的INT0直接相連。片選信號CS由GAL譯碼電路控制，當CS接到低電平時，SJA1000被選中，CPU可對SJA1000進行讀／寫操作。為了增強控制節點的抗干擾能力，防止線路間串擾，SJA1000通過光耦6N137與82C250相連，從而使總線上各個CAN節點之間實現隔離，以保護CAN控制器正常工作。82C250是CAN總線收發器，是CAN控制器SJA1000正常工作與CAN總線的接口器件，對CAN總線以差分方式發送。其引腳RS用于選擇82C250的工作模式(高速、斜率控制或等待)。RS腳接地，82C250工作于高速方式，RS腳串接一個電阻R后再接地，若82C250處于CAN總線的網絡終端，總線接口部分必須加一個120Ω的匹配電阻，以保護82C250免受過流的沖擊。

1．2．2A／D模塊設計

A／D芯片選用12位高速采集芯片AD574。在本設計中，A／D模塊的功能是將外部模擬信號通過AD574轉換成數字信號后并行輸入到AT89C51，然后AT89C51將其打包，并行輸出至CAN總線通信控制器SJA1000，經總線收發器至CAN總線。其監控電路采用DS1232，它具有電源監控、手動復位和看門狗功能，還能同時輸出高低電平的兩路復位信號，分別輸出至AT89C51和SJA1000的復位端，以滿足本次設計的要求。

2軟件設計

本健康監測系統要求軟件部分具有現場數字信號顯示、檢測并驅動現場信號設備等功能。在本設計中主要完成兩部分任務：第一是PC機部分的上位機顯示，主要通過集成開發環境軟件設計出上位機監視顯示界面，其重點在于PC機與現場節點間的通信；第二是現場節點控制設計，即設備驅動功能的實現，目的是能接收上位機的控制信號，使現場節點按既定的工作方式工作。

根據系統的工作要求，工作重點包括CAN總線通信程序、看門狗的初始化、A／D采樣控制程序、執行機構控制程序和控制算法等，主要流程如圖4所示。限于篇幅，這里著重介紹SJA1000初始化程序設計、發送程序設計、接收程序設計以及A／D轉換程序的設計。

2．1SJA1000初始化設計

初始化流程圖如圖5所示。AT89C51上電或復位后，調用復位程序給SJA1000的復位端(RST)提供復位信號，使SJA1000進入復位模式。SJA1000的初始化只有在復位模式下才可以進行。初始化程序主要完成以下寄存器的設計：(1)通過對SJA1000的時鐘分頻寄存器定義，判斷是使用BassicCAN模式還是使用PeliCAN模式；是否使能CLOCKOUT及輸出時鐘頻率；是否使用旁路CAN輸入比較器；TX1輸出是否采用專門的接收中斷。(2)通過寫驗收碼寄存器和驗收屏蔽寄存器定義接收報文的驗收碼，以及對報文和驗收碼進行比較的相關位定義驗收屏蔽碼。(3)通過寫總線定時寄存器定義總線的位速率、位周期內的采樣點和一個位周期內的采樣數量。(4)通過寫輸出寄存器定義CAN總線輸出管腳TX0、TX1的輸出模式和輸出配置。(5)清除SJA1000的復位請求標志，進入正常工作模式，這樣SJA1000方可進行報文的發送和接收。

2.2發送和接收程序設計

單片機將要發送的報文送到SJA1000的發送緩沖區，然后將SJA1000命令寄存器的發送請求標志位(TR)置位，發送過程由SJA1000獨立完成。在新報文寫入發送緩沖區之前，必須檢查狀態寄存器的發送緩沖器的狀態標志位(TBS)，若為“1”，則發送緩沖器被釋放，可將新的報文寫入發送緩沖器；否則，發送緩沖器被鎖定，新的報文不能被寫入，發送程序可以采用中斷方式和查詢方式。在本次設計中，采用的是查詢方式。

報文的接收也是由SJA1000獨立完成的。收到的報文通過接收濾波器存放在FIFO中，第一條報文進入接收緩沖器，由狀態寄存器的接收緩沖器狀態標志位(RBS)和接收中斷標志位(RI)標出。單片機從接收緩沖器取走一條報文后，要通過置位SJA1000的命令寄存器來釋放接收緩沖器。在本次設計中，接收程序的設計采用的是中斷方式。

2．3A／D轉換設計

第9篇：分布式系統設計與應用范文

【關鍵詞】數據采集與監視控制；長輸管道；集中式結構；分布式結構

1.長輸管道監控特點

長輸管道一般分布廣泛、站點較多，輸送介質多為天然氣、原油、成品油、液態天然氣、水和其他液態化工產品等。一般采用密閉輸送流程，所有泵站、壓氣站、分輸下載站、配氣站、截斷閥室和管路等構成完整的水力系統。因此，長輸管道一般設立調度控制中心由SCADA系統進行集中監控、統一調度，實現中心控制、站控和就地控制相結合的控制方式。有的管道設立站點監控，有的并不設立站點監控，而是通過調度控制中心統一進行管理。站點的遠程端由PLC或RTU進行數據采集和監督控制，將控制數據傳輸到調度中心，從而完成整個管道的自動化控制。長輸管道的通信系統是決定整個SCADA系統可靠性和有效性的重要基礎，目前多采用自建光纖、衛星、微波、電話等多種方式，不同的通信基礎直接決定了SCADA系統調控中心數據庫系統結構的選擇方式。通過以上分析，可以看到非光纖通信條件下，長輸管道要求SCADA系統設計必須滿足低速和有限帶寬的長距離通信要求。在SCADA系統中，控制器中的數據以非常小的數據包進行傳輸，許多歷史數據存儲在中心數據庫中。監控數據以逢變則報或進行內部輪詢以達到最小數據的目的傳輸，并且控制器都具有歷史回填的功能，在通信恢復時，能夠將傳送失敗的歷史數據重新傳輸到中心數據庫，以保證數據的完整性。

2.長輸管道SCADA系統國內外現狀及發展

SCADA系統是建立在數據庫基礎之上的一系列應用軟件的組合，其主要功能有系統模擬圖實時監控―實時監測沿線各站庫生產運行數據；歷史數據分析―包括歷史數據曲線、超限額運行時間統計等。經概括，SCADA系統的硬件構成有四種形式：PC+板卡，PLC，DCS及RTU遠程終端單元，在功能上都有完成數據采集與控制的能力，但它們各有不同的適用范圍。DCS適合于大型生產裝置，如煉油廠、化工廠的大型成套化工裝置，DCS具有獨立的軟硬件，運行穩定可靠；缺點是價格昂貴，擴充麻煩。PLC適用于控制，規模可大可小。RTU則適用于小型局部的場合，優點是通信靈活，計算與數據存儲能力強，如用于輸氣管道進出口的流量采集，天然氣計量采用RTU產品，具有明顯的甚至不可替代的優勢。可實現SY/N6143計量標準嵌入式應用，大幅提高可計量程序運行的可靠性和實時性；流量累計等重要數據在RTU內做備份，而不僅依賴傳統的計算機做數據備份，即使計算機和通信設備出現故障，數據依舊可恢復，大幅提高了數據存儲的安全性。SCADA系統由 PLC和通信技術共同發展而來，具備高度靈活的通信方式；可選擇自建光纖，租用公網，衛星通信，CDMA，GPRS等有線和無線通信方式；根據不同的通信方式選擇適合的通信協議，目前常用的有DNP，OPC，CIP，Modbus TCP/IP，IEC60870-5-104 TCP/IP 等；可根據施工和投資的具體方案及數據通信所需帶寬的要求，選擇合適的通信方式。基于目前采用集中控制的要求，一般設有兩個獨立的物理網絡，并保證SCADA 通信系統的冗余性。

3.調度控制中心數據庫的集中式和分布式結構

集中式系統結構雖然效率高，但由于負荷集中，計算機硬件和軟件的擴充受到限制，目前國外很多廠家的遠程站點的數據庫都限制在25000點以內。如中石油北京油氣調控中心，由于不同管段的建設時間不同，其選用的 SCADA系統不同，造成調控中心必須選取集中式系統結構。其天然氣管道，為保證調度中心SCADA 系統的穩定性，將所有站點分為幾套服務器分別進行處理。在這種特大型結構中，必須選擇最佳數據存儲方法和訪問結構，集中式也要解決這些差異問題。再如，中國石化運行的珠三角成品油管道，采用 ABB公司的SCADAVISON集中式數據庫，目前站點為22個，數據點達22000點，也基本達到了它的運行負荷能力。目前，世界范圍內天然氣長輸管道多采用該種結構，需要調度中心數據服務器根據站點數量進行統籌劃分設置。

在集中式數據庫系統和通信技術發展的基礎上產生和發展了分布式數據庫系統，雖然已發展成熟，但工業化控制系統采用這種數據庫的SCADA系統的情況出現在20世紀90年代末，成功推出應用的也不是很多。各個站點服務器的采集數據原理同集中式；區別在于調度中心總服務器對各個站點服務器數據庫進行實時訪問，通過一定的數據訪問權限和驗證模式的設置和授權形成了全局共享結構，實現了全局數據庫信息的調用。歷史存儲信息分布在各個遠程站點中，站點中的數據庫服務器的數據實時到調度中心總服務器內存中，調度中心總服務器僅對重要數據進行處理和歸檔，而實時操作日志分別存儲在調度中心總服務器和相應數據源的站點服務器中，從而實現了數據、網絡優化的高效數據庫。目前典型應用的場合是中國石化的西南成品油管道，全線共21個站點，2座調度控制中心。這種分布式數據庫實現了對處于極度分散的遠程數據的無縫訪問，實現操作控制信息的交互、動態調整用戶和信息應用需求。不同數據庫間的歷史查詢，避免了數據庫的復制，同時避免了控制層 PLC控制器數據的雙重響應。實時數據、報警、操作日志只有在發生變化時才會遞交給調度中心服務器；沒有設置內部系統的輪詢機制，也降低了對通信系統的要求。雖然目前工業用分布式數據庫系統還處于中小型階段，能否向更大數據庫的規模化發展，受到通信系統、計算機和軟件應用系統的可用性、可靠性及數據的存取效率等的直接影響，有待理論的進一步突破。

4.集中式和分布式系統結構比較

兩種數據庫技術在工業領域都有實際的應用，分布式系統結構是在集中式系統結構的基礎上發展起來的，但并不是簡單地將集中數據庫分散到不同的場地，它在實現數據庫的獨立性、數據共享、數據冗余、并發控制、完整性、安全性、事務處理等方面具有更加豐富的內容。分布式數據庫較集中式數據庫有著自己不可替代的優勢，若網絡結構中通信恢復、診斷、優化的問題能得到解決，必將在SCADA系統和生產管理系統等融合擴展方面取得更大的發展。

5.結束語

集中式系統結構的SCADA系統作為經典、成熟的結構方式，已在長輸管道領域得到廣泛的應用；而分布式系統結構是數據庫技術和網絡技術兩者相互滲透和有機結合的成果。作為一門創新技術，若網絡結構中通信恢復、診斷、優化的問題能得到解決，分布式系統結構的SCADA系統將有更加長足的發展。因此，在實際應用中要靈活選用，根據系統的安全可靠性和運行模式要求配置主控中心、備用控制中心、分控站和站控，最大限度地發揮不同結構的作用。

【參考文獻】

[1]田洪波，姜波，武建宏.SCADA系統在長輸管道的應用和發展[J].石油化工自動化，2008，（04）.