目       錄

C#通訊（串列埠和網路）框架的設計與實現... 1

（SuperIO）- 框架的總體設計... 1

第二章           框架總體的設計... 2

2.1           宿主程式設計... 2

2.2           通訊機制設計... 7

  2.2.1    串列埠通訊機制... 8

     2.2.1.1   輪詢模式... 9

  2.2.2    網路通訊機制... 9

     2.2.2.1   輪詢模式... 9

     2.2.2.2   併發模式... 10

     2.2.2.3   自控模式... 11

2.3           層次示意圖... 12

2.4           模型物件示意圖... 13

2.5           小結... 13

第二章     框架總體的設計

2.1    宿主程式設計

    作為外掛式應用框架，要有一個宿主程式來承載、載入外掛，為外掛、驅動提供可執行的環境，使宿主程式與外掛無縫對接。宿主程式與外掛的關係是水和魚的關係，有水沒魚，水就失去了價值；有魚沒水，魚就會死去。從關係的角度來分析，開發框架的目的是什麼？是與其他事物發生關係，包括：開發者、二次開發者、應用者、外掛、甚至其他軟體或元件等。發生的關係越多、相處越融洽，證明這個框架的價值越高。所以說，一個好的框架平臺，不僅體現了開發者的技術，同時反應了開發者的情商。

    SuperIO框架使用NET反射技術開發外掛管理機制，在本章中不詳細介紹具體的技術細節，在《第8章 外掛引擎設計》中再進行詳細的介紹技術應用。

    那麼一個框架的宿主程式應該怎麼樣去設計呢？或是說從哪些方面去考慮設計問題？在開發SuperIO框架的時候，一直在思考這個問題。首先，這個問題不應該從技術角度去考慮，而應該從人的角度去考慮如何做，應用者的角度、二次開發者的角度來規劃宿主程式。

    從應用角度來分析，宿主程式應該包括：使用者管理、裝置驅動管理、裝置狀態監視方式、自定義UI外掛顯示方式、自定義輸出資料外掛操作方式、服務外掛的服務方式、軟體執行的監視方式、串列埠IO通道監視方式、網路IO通道監視方式等等。這些是我們從大的方向規劃的，還需要再進一步細化，指引我們的開發工作。

    使用者管理，要支援多使用者以及使用者許可權分配。針對實時資料採集框架，面對現場應用的時候，肯定會涉及到兩個角色：使用人員、工程師人員。針對使用人員的許可權定位：可以檢視引數和資料資訊。針對工程師人員的許可權定位：不僅擁有使用人員的許可權，還可以修改引數。使用者管理的選單，如下圖：

     裝置驅動管理，裝置驅動（外掛）是通過介面、抽象類設計的框架核心部分之一，可以把二次開發好的裝置外掛載入到框架中執行，完成資料採集、校驗、解析、處理等相關操作，以及進行命令、資料的互動。同時，裝置驅動管理還應該具體刪除相關的裝置外掛的功能。增加裝置外掛，如下圖：

     裝置狀態監視方式，我們可以把它稱為“裝置執行器”，它並不是對不同型別裝置驅動的所有引數、屬性等資料進行簡單顯示，而是對裝置通用引數、屬性、實時狀態等資料進行顯示、監視，例如：裝置ID、裝置名稱、地址、通訊型別、IO引數、IO狀態、通訊狀態、裝置狀態、報警狀態、裝置型別和編號等。如下圖：

     自定義UI外掛顯示方式，二次開發者在規範的介面基礎上開發資料顯示方式，掛載到框架的配置檔案中，當用戶單擊某一個顯示檢視的時候，以Tab Form的形式顯示，並且可以單擊按鈕進行關閉，如下圖：

     自定義輸出資料外掛操作方式，這種輸出資料的是對實時資料的匯出，更多的是以事務性的服務存在，可以把一類的裝置資料輸出成多種資料格式。輸出資料外掛可以通過配置檔案進行載入，只要裝置驅動有資料更新，就把資料通過介面傳遞給輸出資料外掛，進行輸出操作。不在配置檔案中配置外掛資訊，則程式不進行載入，不進行輸出操作。所以，這種事務性的服務不需要介面來完成，可以在宿主程式啟動時通過程式碼來完成。

     服務外掛的服務方式，這種服務是長期執行的事務性任務，所以更復雜一些。有些服務需要隨宿主程式啟動而自動執行，有些服務需要人工手動啟動才執行。在宿主程式啟動的時候要把服務的資訊載入到選單上，選單裡顯示的這些服務可能有些已經啟動了，有些需要通過單擊操作，顯示窗體並填寫必要的資訊後才可能啟動。所以，宿主程式與服務外掛不是單向互動，而是雙向資料、事件互動。例如：把裝置的資料採集上來、處理之後，要把資料上傳到服務中心或其他區域，就可以開發一個外掛來完成這項任務，如下圖：

     軟體執行的監視方式，這是一種實時日誌監視器，可以監視框架執行情況、以及裝置的執行情況。把異常的資訊可以友好的顯示出來，把異常的詳細資訊儲存到日誌檔案。我們可以把它稱為“執行監測器”，對於實時資料採集框架的執行是很有幫助的。如下圖：

     串列埠IO通道監視方式，當某一個裝置驅動以串列埠方式通訊時，當串列埠引數動態發生改變時會在串列埠監視器反映當前串列埠IO狀態，例如：增加串列埠、刪除串列埠、串列埠號和波特率的改變等。如下圖：

     網路IO通道監視方式，相對好設計一些，只需要對Socket例項的連線和斷開進行事件反映，Socket例項有效時把資訊增加到網路監視器中，Socket例項無效時，並釋放了相關資源後，從網路監視器刪除相關資訊。如下圖：

      基於以上的分析，我們需要構建一個完整的宿主程式，必要的功能要有，但是這個程式不一定很複雜，因為有些功能、響應、屬性、資料等可以放到裝置外掛中完成，在《第3章   裝置驅動的設計》中詳細介紹設計情況。構建的宿主程式，如下圖：

     如果光有了宿主程式，那麼還沒有分析全面。還需要以二次開發者的角度分析宿主程式是否能夠與二次開發者保持良好的關係。這裡涉及到宿主程式存在的形式問題，宿主程式作為SuperIO框架的一部分，是一個整體的元件。希望二次開發者繼承宿主程式就可以快速構建一個自己的主程式，可以在此基礎上擴充套件功能，這樣的話，需要把宿主程式的關鍵控制元件的訪問許可權設定成protected。另外，宿主程式還需要一個配置檔案，把二次開發者關心的引數可設定，例如：標題、版本號、公司名稱等。

    經過上述的過程，我們就對宿主程式有一個清晰認識和規劃。介面的骨架已經搭建出來，在後期的開發過程序中從細節著手，逐步實現這些功能。但是，這樣一個簡單的介面需要很多類、模組等支撐。以後章節會對每個模組進行詳細設計說明。                                

2.2    通訊機制設計

    對於實時資料採集框架，通訊部分始終是軟體的核心，要求高實時性、高穩定性。軟體框架決定了軟體執行的穩定性，以及以後的擴充套件性，所以需要對通訊機制、控制方式進行良好的設計。

    在《1.通訊框架介紹》中的已經對應用場景進行了介紹，所以決定了軟體框架在通訊方面的應用有兩種方式：主動請求和被動接收。

    主動請求方式又可以稱之為呼叫應答方式或主從方式。也就是說，主動權在軟體框架端，只有軟體框架主動傳送請求命令，從機（硬體裝置、感測器等）接收到命令後並且檢驗資料的完整性，以及確定是否發給自己的命令，校驗成功後，返回指定的資料資訊，完成一次完整的鏈路通訊過程。呼叫應答通訊方式，如下圖：

   被動接收方式是軟體框架實時監測IO通道，只要有資料資訊就會提取出來，進行資料校驗，檢驗成功後，分析、處理、儲存資料資訊。例如裝置、感測器等定時傳送狀態資料。這種通訊方式，如下圖：

    在複雜的應用場景中，這兩種通訊方式都有可能存在，此類情況一般是採用乙太網鏈路進行通訊。針對只有外接串列埠的裝置可以通過乙太網轉換模組來接入。

2.1.1    串列埠通訊機制

由於串列埠通訊的特性限制，避免多個硬體裝置連線到串列埠匯流排出現數據混亂

現象，一般採用輪詢模式的呼叫應答通訊機制。

2.1.1.1     輪詢模式

當有多個裝置連線到通訊平臺時，通訊平臺會輪詢排程裝置進行通訊任務。某一時刻只能有一個裝置傳送請求命令、等待接收返回資料，這個裝置完成傳送、接收（如果遇到超時情況，則自動返回）後，下一個裝置才進行通訊任務，依次輪詢裝置。如下圖：

2.2.2    網路通訊機制

   輪詢通訊機制是保證資料有序的傳送、接收，避免併發資料在串列埠總線上出現混亂，但是這種通訊機制是以降低效能為代價的，適用於串列埠通訊，在乙太網通訊中顯然無法充分利用網路通訊的優勢。乙太網是獨立通道、可以全雙工通訊。為了充分發揮乙太網的優勢，在輪詢通訊機制的基礎上增加了併發通訊模式、自控通訊模式。一是為了提高通訊的效能，二是為了二次開發有更多自主控制權。

2.2.2.1     輪詢模式

   乙太網輪詢通訊模式與串列埠通訊模式一致，如下圖：

2.2.2.2    併發模式

     併發通訊模式是集中傳送所有裝置的請求指令，現在SuperIO框架是採用迴圈同步方式傳送請求命令。還有進一步提高的機會，採用並行非同步方式集中傳送請求命令。硬體裝置接收到指令後進行校驗，校驗成功後返回對應指令的資料，通訊平臺非同步監聽到資料資訊後，進行接收操作，然後再進行資料的分發、處理等。如下圖：

2.2.2.3    自控模式

     自控通訊模式與併發通訊模式類似，區別在於傳送指令操作交給裝置驅動本身進行控制，或者說交給二次開發者，二次開發者可以通過時鐘定時用事件驅動的方式傳送指令資料。硬體裝置接收到指令後進行校驗，校驗成功後返回對應指令的資料，通訊平臺非同步監聽到資料資訊後，進行接收操作，然後再進行資料的分發、處理等。

      自控通訊模式可以為二次開發者提供精確的定時請求實時資料機制，使通訊機制更靈活、自主。如下圖：

      併發模式和自控模式都可被動接收資料，應用場景更加靈活，使軟體框架和硬體裝置的開發過工作更自由。

2.3   層次示意圖

2.4    模型物件示意圖

2.5    小結

   框架的總體設計是指引開發的方向性的原則，保證在後續開發的過程不偏離我們思考的初中。宿主程式規範了應用的方向、通訊機制規範了互動的原則、以及在層次上、物件模型上進一步解構框架的組成。

   層次示意圖和模型物件示意圖是後來補充畫的，這部分工作應該在框架開發前就應該進行規劃，這對理解框架很有幫助，並且可以避免減少走彎路的可能性。

下一章：第3章 裝置驅動的設計

作者：唯笑志在

Email：[email protected]

QQ：504547114

.NET開發技術聯盟：54256083