摘要:論述設計通信規約管理平臺的必要性與可行性;借鑒操作系統的PCB思想,結合面向對象的方法學提出通信規約管理平臺設計的核心思想——用戶填寫靜態規約說明書。規約管理平臺根據規約書生成通信規約控制塊,由規約控制塊控制、管理并適應千差萬別規約程序的運行。 關鍵詞:平臺 規約說明書 CPCB 動態描述靜態描述 邏輯描述 引言 眾所周知,通信的雙方必須遵守相同的協議,報文才能互相識別。目前,不同行業間的通信協議千差萬別。為解決不同通信協議間的計算機系統通信問題,人們普遍采用的措施是一個具體規約對應一段程序。如果出現新規約,只能由通信雙方共同配合,由一方按另一方的標準修改或增加通信規約來解決問題。這種解決措施使得通信系統的適應能力不強、可維護性差,難以兼容不同規約的設備。 筆者借鑒操作系統進程控制塊PCB的思想,通過對各種通信規約的認真分析研究,提出了自己的通信規約管理平臺的核心設計思想——用戶填寫指定格式的靜態規約說明書。規約管理平臺根據規約書生成通信規約控制塊,由規約控制塊統一控制、管理,并適應千差萬別規約程序的運行。 該平臺的設計使得系統能夠適應千差萬別的通信規約,不用修改程序就能夠保證通信系統在線運行情況下,接入各種新設備,以不變的程序應對萬變的規約,維護真正做到傻瓜化、智能化。 1 設計通信規約管理平臺的可行性 1.1 統一的通信模型 任何兩臺計算機上的兩個應用程序通信,都遵從如圖1所示的通信模型。數據流動可以用收到發兩個動作來描述。把提出數據請求服務的應用程序稱為控制方向、即命令的下行;把提供數據服務的應用程序稱為監測方向,即數據的上行。這樣,一個完整的規約有控制方和監測方兩個方面??刂品较蛳掳l送命令,并解析監測方發來的應答或主動上報的數據或狀態指示報文;監測方解析命令,根據請求命令組織應答報文并上傳。 1.2 通信規約的共性 任何通信規約都具有如下共同特征;幀結構的相似性、數據對象種類和報文長度的有限性、報文流的粒子性、邏輯過程的有窮性、傳送原因的可分類性。 (1)幀結構的相似性 每幀報文都有圖2所示的傳輸控制部分。 傳輸控制部分的目的之一是保證要傳輸的數據最終能夠正確到達目的地。傳輸控制部分包括同步字對象、長度對象、傳輸方向對象、源地址對象、目的地址對象、幀號對象、功能符對象、結束符對象、其它對象及校驗碼十種對象構成。任何具體的規約都是上述對象的全部或基子集的一個具體排列。 數據部分就是用傳輸控制元素封裝起來的傳輸數據。 (2)數據對象種類和報文長度的有限性 數據對象是通信規約真正要傳輸的對象。任何一個具體應用,要傳輸數據對象的種類是有限的,因而人們能夠通過具體的通信規約將其進行描述。通信規允管理平臺同樣也能被描述出來。 任何規約一幀報文的最大長度都是有限的,這樣不但可以遏制通信線路上長期被個別設備獨占,也減少了錯誤傳的次數與重傳時間。一旦要傳輸的數據超過規定幀長,要分幀發送,接收方根據幀號來組裝源數據。 (3)報文流的粒子性 更重要的是任何報文流的最小單位都是一個二進制位,相應報文的最小定義單元也是一個二進制位,這是所有通信規約的共性,不同的是各位間含義不同。任何規約的不同定義都在報文流有不同的確定位置(對位而言),數據發送是以字節為單位的。所以,引入順序號的概念來描述并指示定義在不同報文中的起始位置(相對于合法報文的第一個同步字)和位數,順序號屬性就成了所有對象的共同屬性。描述如下: *字節序號——定義在一個以字節為單位,合法幀中數據成員占有的邏輯序號,第一個起始符為邏輯序號0(C、C++下標從0開始),根據在數據流中出現的先后順序遞增; *字節內的起始位號——字節內的開始位號,取值范圍0~7; *位數——用幾位表示。 struct CommSerial {unsigned int SerialByte; unsigned char ByteStartBit,ByteEndBit}my={2,0,8}; 字節順序號為2,字節內起始位號為0,位數為8,說明是幀中的第三個字節。如果規約用已有定義的字節的空位來定義,順序號可以重復,但位號不能重復,用累加實現。 (4)邏輯規則的有窮性 邏輯規則包含以下四個方面。 ①命令應答關系規則:包括通信雙方中,控制方發送的命令和監測方的應答數據對應關系,以及監測方的狀態指示和控制方的發送命令關系兩個方面。這種對應關系是確定的、有限的和可描述的。 ②雙方數據發送的時間規則:控制方的自動輪詢時間規則、監視方主動上報的時間規則及人工隨機干預的控制命令,以上都是有限的與確定的。 ③優先級規則:控制方同時出現多種要發送的命令,應按優先級規則進行傳送。 ④在幀結構的各控制元素一級封裝下,數據對象本身又進行了二級封裝。這種二級封可按一級封裝的方式解決。 (5)傳送原因的可分類性 控制方的傳輸原因有自動輪詢、人工隨機干預、監視方出現需優先處理的狀態或指示;監視方向的傳輸原因有受召喚與主動上報兩種。 綜上所述,通信規約管理平臺的設計是完全可行的。 管理平臺組織方式是將規約按照統一格式分解,以形成規約說明書或規約描述文件,將之放在外存,啟動注冊命令,管理平臺將規約說明書進行系統注冊,填入規約注冊控制表。運行時,管理平臺從規約注意表中提取指定的規約說明書,并找到一個空白規約控制塊CPCB,根據規約說明文件填寫CPCB,再由CPCB控制管理這個具體規約的運行??瞻滓幖s控制塊的個數是有限的。一個進程按照CPCB的內容來運行,同時一個進程管理一個硬件通信端口資源,即通信端口的數量決定通信進程的數量。平臺可根據運行各規約的實現性要求,來安排一個進程運行CPCB的數量。當然,一個進程依照一個CPCB運行是容易實現的。 2.1 規約說明書 規約說明書由基本情況表、靜態描述表、動態描述表、邏輯規則表構成。靜態描述表由控制元素對象中不隨時間變化而變化的屬性信息及其它信息組成;動態描述表用于描述隨時間不斷變化的控制元素和數據元素信息及其它信息;邏輯描述表由命令應答關系表、應答命令表、時間規則表、優先級規則表、篩選規則表和二級封裝規則表組成。 (1)基本情況表 包括規約名稱、最大幀長、數據對象個數、命令對象個數和狀態指示對象個數,如圖3(a)所示。 (2)靜態描述 由同步字、傳輸方向、源地址、結束符及其它6種數據對象構成,如圖3(b)所示。同步字標志一幀數據的開始;傳輸方向說明當前是工作在控制方向還是標志測方向;源地址說明報文的發送設備地址;結束符標志一幀報文的尾;其它對象指向所有不在上述靜態描述之中的控制元素對象鏈的隊首。靜態描述中的每個控制元素對象都有本規約內全局統一的標識號(ID)。 (3)動態描述 用于描述隨時間具體因素控制而不斷變化的信息,它包括幀號對象、校驗碼對象、報文長度對象、數據對象、請求命令對象、應答命令對象、目的地址對象及其它對象,如圖3(c)所示。幀號是完整報文的分幀傳送,規約規定的報文幀的幀長是有限的;超限時分幀傳送,發送方指明幀號,接受方按幀號重新組裝。校驗碼對象用于傳輸差錯控制,檢驗一幀報文的合法性。報文長度對象管理并指明有效數據的長度。數據對象按應答命令對象指明的類型組織該類數據。目的地址對于控制方向,指明服務的設備地址,它可能向多個設備輪流請求;對于監測方向,指明請求服務的設備地址。數據對象取決于具體規約的定義。應答命令對換快捷指明應答數據對象的類型。請求命令對象指明控制方向,向目的設備下發請求數據狀態對象命令,并組織報文幀。應答命令對象和請求命令對象管理的措施與數據狀態對象相同。當然,應答數據狀態表和請求命令表是靜態的,在此便于說明;而數據狀態對象表是動態的。 動態描述中的控制元素對象和數據元素對象也都由本規約內全局統一的ID號來識別;ID號由ID注冊管理程序生成,填寫規約自己所賂的ID注冊表。 (4)靜態對象和動態對象公有的屬性 ①順序號對象:如前所述,它指明某一元素對象在報文流中的起始位置和所占的連續二進制位數。 ②ID號對象是全局統一的,它由六段依次連接而成,即一段、二段、三段、四段、五段、六段。根據ID可以識別提取不同的元素對象,它是各控制元素和數據元素的唯一標識。 一段是注冊后的規約ID號,高段的位數由規約ID號位數決定。二段是區分上行與下行,用一位二進制位就可區分。三段用于說明具體的規約是否含有對應的元素對象,它說明的是有與無。四段用于區分源地址、目的地址、傳輸方向、同步字、其它靜態對象、幀號、校驗碼、報文長度、請求命令符、應答命令符、其它動態對象和數據對象,共12種,用4位二進制位就可區分。五段用于說明四段之中的每一種是否具有原子性,比如同步字就具有原子性。當子種類多于一個同步字時,也相當于一個,要發就全發,不可分割;而請求命令符就不具有原子性,只能發出其子種類之中的一種。原子性是個布爾量,一位二進制就可描述。六段用于說明當上述12種之中任一種超過一個時,就可用第5段描述,比如同步字6個,就得用三位,選取上述12種之中子種類最多的一個和為第五段的位數。 ③拷貝、賦值、被拷貝:在報文流中的其它類元素對象中,當出現與已有定義的控制元素對象表示值重復時,引進對象的拷貝與被拷貝屬性。賦值屬性說明該元素指的是已獨立的定義值。相應的,引入拷貝與賦值操作。 邏輯描述信息由下列表構成: ①控制方發送的命令被監測方收到后,監測方予以應答的數據對象ID對應關系表; ②控制方收到監測方的狀態指示后,控制方應響應的發送命令ID對應關系表; ③控制方發送輪詢命令ID時間間隔表; ④控制方的人工干預控制命令ID表; ⑤監測方的主動上報數據表、狀態ID表; ⑥控制方發送命令ID優先級的規則表; ⑦監測方應答數據與主動上報的ID優先級規則表; ⑧二級封裝規則表。 2.2 規約控制埠CPCB 通信平臺的某一通信進程在運行時,如未匹配通信規約,則運行空規約。如收到控制臺發來的匹配命令,則從規約注冊表中提取規約說明書,并從空白CPCB鏈表中摘下一個,將它鏈入運行CPCB鏈表,按照規約說明書的內容填寫該CPCB,填寫完畢即投入運行。這樣,在邏輯規則的控制下,各靜態對象和動態對象各司其職而又發送消息協同工作,整個平臺就會有條不紊地動作。 |
- 嵌入式系(13927)
- 平臺設計(5848)
相關推薦
評論
查看更多