【正文】 得用戶完全從低層的開發(fā)中脫離出來。任何一家自動化軟件解決方案的提供者， 4 如果它不能全方位地支持 OPC，則必將被歷史所淘汰。這兩種接口是：自動化接口（ Automation interface）；自定義接口（ Custom interface）。在 Windows 操作系統(tǒng)下， COM 規(guī)范擴展到可訪問本機以外的其它對象，一個應(yīng)用程序所使用的對象可分布在網(wǎng)絡(luò)上， COM 的這個擴展被稱為 DCOM（ Distributed COM）。 COM 是 Component Object Model 的縮寫，是所有 OLE 機制的基礎(chǔ)。由于現(xiàn)場設(shè)備的種類繁多，且產(chǎn)品的不斷升級，往往給用戶和軟件開發(fā)商帶來了巨大的工作負擔。同時， 2 在多 個應(yīng)用程序共享通信設(shè)備時容易產(chǎn)生沖突。對不同類型的通信鏈路必須進行綜合調(diào)度，做到自適應(yīng)不同的網(wǎng)絡(luò)環(huán)境，自動在 主用鏈路和多條備用鏈路間進行切換。在Ｃ 4Ｉ系統(tǒng)中，把現(xiàn)有的和未來的全部傳輸媒介資源 綜合到通信系統(tǒng)中已經(jīng)成為通信網(wǎng)絡(luò)追求的目標之一。這樣才能適應(yīng)這些系統(tǒng)對網(wǎng)絡(luò)生存能力的要求。 33 III 多媒介通信系統(tǒng)鏈路管理的設(shè)計和實現(xiàn) 摘要 軍事通信系統(tǒng)和某些民和領(lǐng)域?qū)νㄐ趴煽啃院涂箽杂兄浅？量痰囊?，既要求在正常情況下有較高的通信效率，又要求在惡劣環(huán)境下能保證基本的通信，因此僅僅依賴單一通信媒介難以達到可靠性的要求。 27 參考文獻 23 多鏈路管理 23 通信鏈路管理軟件 23 通信鏈路管理的方法與原則 19 發(fā)送線程 11 第 2 章 系統(tǒng)設(shè)計 10 C4I 系統(tǒng) 7 TCP 的三次握手 7 TCP/IP 協(xié)議的概念 3 ACK 信號 4 串行化 5 開放系統(tǒng)互連（ OpenSystemInterconnection， OSI）模型 6 跨層通信 7 TCP/IP 協(xié)議的分層結(jié)構(gòu) 9 UDP 協(xié)議 13 模塊化和可擴展性 17 鏈路協(xié)議 17 鏈路層協(xié)議提供的服務(wù) 25 鏈路間切換 26 鏈路間切換方法 31 致謝 通信可靠性和抗毀性的需求使得點到點的鏈路傾向于建立在多種通信媒介、多種協(xié)議上。本系統(tǒng)介紹了一種借鑒OPC 規(guī)范，基于 COM 技術(shù)，在多協(xié)議、多通信媒介上進行鏈路管理和調(diào)度的解決方案，并給出了具體實現(xiàn)。在民用領(lǐng)域，例如高速公路聯(lián)網(wǎng)收費系統(tǒng)中，因為需要一個２４７的可靠通信平臺，亦采用了不同類型的通信媒介 (如圖１ )。這樣才能適應(yīng)這些系統(tǒng)對網(wǎng)絡(luò)生存能力的要求。借鑒超鏈思想以及微軟和工業(yè)控制界共同推出的 ＯＰＣ (Ｏ ＬＥ for process control)規(guī)范的設(shè)計思路，提出了基于 ＣＯＭ 技術(shù)的解決方案。通常這樣也不能滿足工 作的實際需要，系統(tǒng)集成商和開發(fā)商急切需要一種具有高效性、可靠性、開放性、可互操作性的即插即用的設(shè)備驅(qū)動程序。 COM 是一種為了實現(xiàn)與編程語言無關(guān)的對象而制定的標準，該標準將 Windows 下的對象定義為獨立單元，可不 受程序限制地訪問這些單元。 通過 DCOM 技術(shù)和 OPC 標準，完全可以創(chuàng)建一個開放的、可互操作的控制系統(tǒng)軟件。自動化接口通常是為基于腳本編 程語言而定義的標準接口，可以使用 VisualBasic、 Delphi、PowerBuilder 等編程語言開發(fā) OPC 服務(wù)器的客戶應(yīng)用。 由 OPC Task Force 制定的 OPC(OLE for Process Control)規(guī)范于 1996 年 8 月正式誕生了，隨著 1997 年 2 月 Microsoft 公司推出 Windows95 支持的 DCOM 技術(shù)， 1997 年 9 月新成立的 OPC Foundation 對 OPC 規(guī)范進行修改，增加了數(shù)據(jù)訪問等一些標準， OPC 規(guī)范得到了進一步的完善。采用 OPC 規(guī)范設(shè)計系統(tǒng)的好 處 在進行新型微機遠動系統(tǒng)的研制中，各個計算機以及各個模塊的數(shù)據(jù)交換應(yīng)該按照 OPC 規(guī)范進行。 4 采用 OPC 規(guī)范，便于系統(tǒng)的組態(tài)化，將系統(tǒng)復(fù)雜性大大簡化，可以大大縮短軟件開發(fā)周期，提高軟件運行的可靠性和穩(wěn)定性，便于系統(tǒng)的升級與維護。其格式取決 于采取的網(wǎng)絡(luò)協(xié)議。 ACK 信號通常是一個 ASCII 字符，不同的協(xié)議中 ACK 信號都不一樣。 串行化有以下但不局限于這些優(yōu)點： ，如 SOAP ，特別是在軟件組件中，如 COM、 CORBA 等 （ timevarying data）檢測改變 由于這些特性都是十分有用的，所以必須維持串行化的體系結(jié)構(gòu)獨立性。在 1997 年，國際標準組織（ ISO）創(chuàng)建了一個小組委員會來開發(fā)數(shù)據(jù)通信標準以促進多供應(yīng)商的互操作性。這個體系結(jié)構(gòu)就是 TCP/IP 參考模型。 OSI 模型由 7 層組成： 物理層：涉及到通信在信道上傳輸?shù)脑急忍亓鳌? 表示層：為用戶提供數(shù)據(jù)轉(zhuǎn)換和表示服務(wù)。它們一 起處理與電纜（或其他任何傳輸媒介）的物理接口細節(jié)。在 TCP/IP 協(xié)議組件中，有兩個互不相同的傳輸協(xié)議： TCP（傳輸控制協(xié)議）和 UDP（用戶數(shù)據(jù)報協(xié)議）。 應(yīng)用層，負責(zé)處理特定的應(yīng)用程序細節(jié)。例如，網(wǎng)絡(luò)層使用數(shù)據(jù)鏈路層的服務(wù)并為傳輸層提供與網(wǎng)絡(luò)相關(guān)的服務(wù)。通過將這些服務(wù)分開，秘書（應(yīng)用程序）就不必知道消息實際上是如何傳遞到接收者手中。例如，一個系統(tǒng)中的第 3 層與另一個計算機系統(tǒng)的第 3 層通信。當?shù)?3 層將該信息傳遞到第 2 層時，第 3 層會將來自第 4 層的頭加數(shù)據(jù)作為它的數(shù)據(jù)，并在該數(shù)據(jù)前添加第 3 層的頭，然后才將這個“頭 +數(shù)據(jù)”組合傳給下一層。 TCP(Transmission Control Protocol：傳輸控制協(xié)議 )和 IP(Inter Protocol：互聯(lián) 網(wǎng) 協(xié) 議 )是其中最重要的、確保數(shù)據(jù)完整傳輸?shù)膬蓚€協(xié)議， IP 協(xié)議用于在主機之間傳送數(shù)據(jù)， TCP 協(xié)議則確保數(shù)據(jù)在傳輸過程中不出現(xiàn)錯誤和丟失。該模型的目的是使各種硬件在相同的層次上相 8 互通信。幾乎各種不同的 TCP/IP 實現(xiàn)都會提供下面這些通用的應(yīng)用程序： SNMP 簡單網(wǎng)絡(luò)管理協(xié)議 (2)傳輸層 傳輸層 主要為兩臺主機上的應(yīng)用程序提供端到端的通信。它所作的工作包括把應(yīng)用程序交給它的數(shù)據(jù)分成合適的小塊交給下面的網(wǎng)絡(luò)層，確認接收到的分組，設(shè)置發(fā)送最后確定分組的超時時鐘等。任 何必需的可靠性必須由應(yīng)用層來提供。它們一起處理與電纜 (或其他任何傳輸媒介 )的物理接口細節(jié)。 (2)服務(wù)進程返回一個 SYN 和 ACK 都置 1 的 TCP 段，將服務(wù)進程選擇的初始連接序號放入序號域中 (設(shè)為 y)， 并在 確認號域中對客戶進程的初始連接序號進行應(yīng)答 (x+1)。 UDP向應(yīng)用程序提供了一種發(fā)送封裝的原始 IP 數(shù)據(jù)報的方法，并且發(fā)送時無需建立連接。 UDP 長度字段指明包括 8 字節(jié)的頭和數(shù)據(jù)在內(nèi)的數(shù)據(jù)段長度。然后服務(wù)器計算機只需將 RemoteHost 設(shè)置為客戶計算機的 IP 地址，并將 RemotePort 屬性設(shè)置為與客戶 計算機 LocalPort 屬性相同的端口，最后調(diào)用 SendData 方法來發(fā)送信息，而客戶計算機則使用 Data TCP/IP 起源于 60 年代末美國政府資助的一個分組交換網(wǎng)絡(luò)的研究項目，到現(xiàn)在 90 年代已發(fā)展成為計算機之間最常用的組網(wǎng)形式。因為指揮（ mand）、控制（ control）、通信（ munication）的英文第一個字母都是 C 和情報（ intelligence）的第一個英文字母是 I，所以西方國家又把它簡稱為“ C3I”系統(tǒng)。 C3I 的重點在于信息的獲取、傳輸（通信）、處理、評估、選擇和顯示。住處沒有重量，易于復(fù)制 ，能以光速傳播；它在網(wǎng)絡(luò)中傳輸時，時空障礙基本消失；它可供無數(shù)的用戶使用，使用面越廣其價值越高。 1994 年 4 月，美國進行代號為“沙漠鐵錘Ⅵ ”的數(shù)字化部隊重裝備、大編組、高能耗的不靈便。ＯＰＣ規(guī)范通過提供標準接口的方法，使下層設(shè)備無需了解上層應(yīng)用，上層應(yīng)用亦無需關(guān)心下層設(shè)備的細節(jié)。針對不同數(shù)據(jù)類型，設(shè)計具有不同性能的傳 輸 層協(xié)議，并實現(xiàn)自適應(yīng)調(diào)度，是實際應(yīng)用的需求。協(xié)議 1～ n 表示諸如基于 TCP 的協(xié)議、基于 UDP 的協(xié)議、半雙工高速短波協(xié)議以及將來擴展的各種不同協(xié)議，它們的管理同樣 14 由鏈路調(diào)度管理層進行，接口并不直接暴露給上層，而是由管理層封裝后向上層提供統(tǒng)一的接口。這樣就需要設(shè)計和實現(xiàn)做到模塊化，且各模塊和鏈路調(diào)度模塊之間必須隔離開。每個協(xié)議模塊和通信媒介模塊均是一個單獨ＣＯＭ組件，通過接口和回調(diào)接口與鏈路調(diào)度模塊進行通信，鏈路管理模塊以總線方式實現(xiàn)對協(xié)議模塊和媒介模塊的管理。 難點之二，如前文所述，通信媒介組件與物理層密切相關(guān)，很難做到支持并行化的輸入。這種技術(shù)基于ＣＯＭ ＯＲＰＣ協(xié)議 和消息隊列機制，自動把對該對象的訪問串行化了。 數(shù)據(jù)傳輸：數(shù)據(jù)分塊（幀）發(fā)送，并根據(jù)應(yīng)答的類型決定是繼續(xù)發(fā)送還是重發(fā)；鏈路的釋放：終止邏輯連接。對于參數(shù)的設(shè)置和信息查 詢，媒介組件同外界通過不定長度的數(shù)組或字符串交換，這樣在形式上掩蓋了差異，保持了接口的統(tǒng)一性。這是考慮到媒介類型與協(xié)議并非一一對應(yīng)，一種協(xié)議可能適用于多種媒介，一種媒介亦可能使用多種協(xié)議。 鏈路管理協(xié)議 的功能 鏈路管理協(xié)議是為管理流量工程鏈路（ TELink）而開發(fā)的一種新技術(shù)?？刂菩诺拦芾磉^程包括兩個階段，即參數(shù)協(xié)商和連通性維護。 (3)鏈路連通性驗證。 網(wǎng)絡(luò)的故障管理可以分為故障檢測、故障定位、故障隔離、故障通告、故障恢復(fù)五個 過程。這種服務(wù)類型存在 3 個階段，即數(shù)據(jù)鏈路建立、傳輸、釋放數(shù)據(jù)鏈路等階段。但是，源主機數(shù)據(jù)鏈路層必須對每個發(fā)送的數(shù)據(jù)幀進行編號，目的主機數(shù)據(jù)鏈路層也必須對每個接收的數(shù)據(jù)幀進行確認。如果幀傳 輸出現(xiàn)錯誤，將由高層進行檢查與糾正。鏈路層協(xié)議能夠調(diào)整的參數(shù)如下： （ 1）選擇一個合適的工作頻率，合適的工作效率可以把傳播中帶來的衰落、吸收、多徑效應(yīng)以及其他干擾減小到很低。 數(shù)據(jù)通信協(xié)議實現(xiàn)流程 為了實現(xiàn)全雙工通信，創(chuàng)建兩個線程：一個發(fā)送線程、一個接收線程，這兩個線程同時協(xié)同工作。 如果沒有待發(fā)送的數(shù)據(jù)事務(wù)，同時又沒有接收數(shù)據(jù)，則啟動計時器，如果超過 T 就發(fā)送Check 數(shù)據(jù)包來核實數(shù)據(jù)通信是否正常。如圖 20 發(fā) 送 線 程無 限 等 待 發(fā) 送事 件從 發(fā) 送 隊 列 中 取 數(shù)據(jù) 并 檢 測 其 優(yōu) 先 級有 優(yōu) 先 級 1 的 數(shù)據(jù)取 一 個 通 信 事 務(wù)是 否 有 數(shù) 據(jù) 在發(fā) 送逐 幀 發(fā) 送 數(shù) 據(jù)判 斷 此 包 序 列是 否 有 效回 傳 包 序 號 是否 為 結(jié) 尾 包 序號 加 1清 除 此 通 信 節(jié) 點隊 列 中 是 否 事務(wù) 等 待 發(fā) 送線 程 終 止已 發(fā) 送 1 0 幀 或全 部 發(fā) 送 完 ，等 待 回 傳取 出 回 傳 包 序 列重 發(fā) 次 數(shù) 是 否大 于 3重 新 發(fā) 送 ， 重 發(fā) 次數(shù) 加 1通 知 檢 測 線 程 檢 測 網(wǎng) 絡(luò)其 他 優(yōu) 先 級 數(shù) 據(jù) 處理 流 程 和 優(yōu) 先 級 1的 處 理 方 法 相 同 圖 發(fā)送線程流程圖 接收線程 接收線程收到數(shù)據(jù)首先時檢測數(shù)據(jù)包的是 ACK 包，則立刻通知發(fā)送線程，如果收到 了正常的數(shù)據(jù)包，則查看通信事務(wù)期待的包序列與新收到的包序列是否一致，如果一致則認可這一數(shù)據(jù)包，期待的包序列號加 1，如果一直正確則直到滑動窗口包結(jié)尾或者超過包間隔時間，這時確定 ACK 請求包序列號為當前期待的包序列，把 ACK 信號傳遞給發(fā)送線程。同時，鏈路管理層必須實時地獲得各條鏈路的運行狀態(tài)和當前參數(shù)，如通斷情況、吞吐量等，以作出正確的調(diào)度決策。我們采用的是每 2 小時評估一次。檢測的內(nèi)容主要包括