開源純C#工控網關+組態軟體(四)上下位機通訊原理

標籤：上位機   運算式   推送   晶片   分組   技術分享   邏輯   ima   連續   

一、   網關的功能：承上啟下

最近有點忙，更新慢了。感謝園友們給予的支援，現在github上已經有。目標是最好的開源組態，看來又近一步^^

之前有提到網關是物聯網的關鍵環節，它的作用就是承上啟下。

下位機有下位機的語言，上位機有上位機的思路。網關就是一個翻譯，把下位機的語言轉成通用語，再告訴上位機該怎麼做。

這個翻譯的過程，應該保證：

1. 即時性。如果太慢，上下位機明顯不合拍，就會出問題。
2. 精確性。訊號不能頻繁丟失、丟步、跳步；不能有太大誤差；也不會帶入太多幹擾和噪音。
3. 穩定性。如發生故障，如通訊斷開，要能自動重連；要足夠強壯，不會動輒崩潰；發生意外崩潰，要能自動重啟；要有容錯機制和錯誤記錄檔；等等。

要實現這些指標，還是很有挑戰的。

二、   通訊藍本：OPC規範

網關看上去是個很玄奧的東西，網上找來很多相關資料，發現都集中到一個點：OPC規範。

OPC就如一盞明燈，照亮了前進的方向。OPC規範是大家手筆，集中了業界專家的智慧，站在巨人的肩膀上，可以少走很多彎路。

OPC規範定義了資料的採集、歸檔、警示以及完整的介面示範。

OPC資料擷取規範，包含了這樣一些重要概念：

1. 資料讀寫方式包括下位機批量推送資料、上位機單獨讀寫資料。
2. 可以非同步讀寫，也可以同步讀寫。
3. 資料包括中繼資料（資料的屬性，如資料類型、長度、名稱等）和過程資料（ID、數值、時間戳記、品質戳）。
4. 包含驅動(Driver)-組（Group）-變數（Item）的三級架構。可以對變數按需分組，有的組唯讀，有的組需要1秒重新整理一次，有的只要5分鐘就可以，要加以區別以提高效率。
5. 要能判斷驅動程式是否斷線、要提供斷線或關閉的事件供應用程式處理。

  

總之，資訊量很豐富，啟發很大，我的網關程式很大程度上都參考了OPC規範。

但是OPC有它固有的缺陷：依賴微軟的COM組件技術，不能跨平台，同時COM是一種過時的技術，在不同主機上通訊的配置十分繁瑣且不安全。

因此，我改造實現了自己的類OPC伺服器。基本通訊過程是：批量輪詢下位機-與上個周期的資料比對-提取變化的資料-批量推送給上位機。

三、   與下位機通訊：批量輪詢

• 下位機的特點-為什麼要採用輪詢

下位機通訊的特點：

1. 下位機很多採用主-從模式。即主機發送的資訊可以傳送到各個從機或指定的從機,而各個從機的資訊只能發送給主機。主機採用查詢方式接收發送資料,從機採用中斷方式接收發送資料。這種模式天然適合輪詢。
2. 下位機多數只有一個通訊口，有些還是串口，天然不適合推送模式。
3. 下位機很多是單片機，訂閱-發布模式往往邏輯較為複雜，程式編寫難度大，對晶片及儲存要求也必然提高。因此採用這種模式的下位機目前極少。

輪詢就是網關作為主機，定期請求下位機的資料。如果實現批量請求，減少往返，輪詢的效率並不低。幾千個變數輪詢周期500毫秒（西門子），無壓力。

輪詢是以組（Group）為單位的。Group都繼承自IGroup 介面：  

 public interface IGroup : IDisposable    {        bool IsActive { get; set; }        short ID { get; }        int UpdateRate { get; set; }        float DeadBand { get; set; }        string Name { get; set; }        IDriver Parent { get; }        IDataServer Server { get; }        IEnumerable<ITag> Items { get; }        bool AddItems(IList<TagMetaData> items);        bool AddTags(IEnumerable<ITag> tags);        bool RemoveItems(params ITag[] items);        bool SetActiveState(bool active, params short[] items);        ITag FindItemByAddress(DeviceAddress addr);        HistoryData[] BatchRead(DataSource source, bool isSync, params ITag[] itemArray);        int BatchWrite(SortedDictionary<ITag, object> items, bool isSync = true);        ItemData<int> ReadInt32(DeviceAddress address, DataSource source = DataSource.Cache);        ItemData<short> ReadInt16(DeviceAddress address, DataSource source = DataSource.Cache);        ItemData<byte> ReadByte(DeviceAddress address, DataSource source = DataSource.Cache);        ItemData<float> ReadFloat(DeviceAddress address, DataSource source = DataSource.Cache);        ItemData<bool> ReadBool(DeviceAddress address, DataSource source = DataSource.Cache);        ItemData<string> ReadString(DeviceAddress address, DataSource source = DataSource.Cache);        int WriteInt32(DeviceAddress address, int value);        int WriteInt16(DeviceAddress address, short value);        int WriteFloat(DeviceAddress address, float value);        int WriteString(DeviceAddress address, string value);        int WriteBit(DeviceAddress address, bool value);        int WriteBits(DeviceAddress address, byte value);        event DataChangeEventHandler DataChange;    }

 其中，UpdateRate就是輪詢周期。DeadBand是死區。死區代表敏感度，設的小敏感度高，但也帶來更多的雜訊。

每個Group的變數可支援單獨讀寫（如各ReadXXX,WriteXXX方法），也支援批量推送（DataChange事件）。對下位機的輪詢，都是以組為單位，每個組在啟用狀態下按照自己的輪詢周期，採集、推送資料，互不干擾。

每個Group包含特性相似的一組變數：有相同的輪詢周期、啟用屬性（需要輪詢或無需輪詢）、讀寫屬性（均為唯讀、讀/寫或唯寫），需要的話可以同時使能或同時屏蔽。

因為部分變數無需隨時監控，可以將其劃入一組，不重新整理（輪詢）；有些變數變化很快，需要高頻掃描；有些變化很慢也不需要時時查看，可以幾分鐘輪詢一次。將變數有效分組可以提高對重點監控變數的讀寫效率，減少對下位機資源的佔用。

網關如果有多個用戶端相連，各自需要的資料又不盡相同，由網關統一定期輪詢，再批量推送給用戶端是很高效的。

就比如開超市，南來北往的客人（用戶端）需求各異，但超市（網關）來統一採購（輪詢），不用客戶跟各個批發市場（下位機）直接訂貨，集中來我這購物（訂閱Tag）就行。

• 未來的擴充

雖然當前主流PLC不都支援訂閱-推送模式，但這是曆史潮流。AB Controllogix、新的西門子S71200-1500,都支援標籤地址，也就是直接推送變化的標籤（Tag）資料。

未來考慮制定一個新的介面支援這一模式。

四、   與上位機通訊：訂閱-推送

•  上位機的特點-為什麼要採用訂閱-推送

上位機通訊的特點主要為：

1. 要及時、準確瞭解下位機的訊息。無論是監控畫面、還是警示、提示人工操作這些，越即時越好，越準確越好。如果採用要求-回應模式，請求的周期決定即時性不會太好。請求頻繁網關壓力大，反之即時性差。
2. 一個網關可能要拖好幾個上位機，工段多的，可能要開十幾個顯示屏同時監控。因此，每個上位機都向網關請求資料，流量會陡然上升，網路會阻塞，網關壓力會很大。
3. 大部分上位機需要的資料不會經常變化，尤其是一些開關量。如果每次反覆請求，浪費資源，浪費時間。
4. 如果採用對各變數單獨請求資料，勢必造成大量不同時段要求-回應過程交錯發生，難以整合，也難以批量讀寫，效率極低。

因此，向訂閱客戶只推送變化的資料，無疑是一種高效的辦法。只要資料發生變化，馬上推送給用戶端，既保證了即時性，又保證了推送資料的最小化。

就像打報修電話，送修單位（下位機）不一定時時刻刻有人上門；電話打過去，總台（網關）記下號碼，有人上門（下位機有資料變化）了通知（推送）您。沒人你也不用幾秒鐘打一個催（輪詢），你煩大家煩。

• 如何?訂閱-推送

推送是只推送變化的變數。要知道哪些變數變化了，必須要緩衝上一次變數的資料加以比對。因此，需要緩衝每次輪詢的資料。

網關在對下位機的輪詢過程中，將訂閱的變數都掃描了一遍；這些資料都存在記憶體的變數緩衝：ICache：

        public interface ICache : IReaderWriter        {        int Size { get; set; }        int ByteCount { get; }        Array Cache { get; }        int GetOffset(DeviceAddress start, DeviceAddress end);}

 首先，ICache 繼承了IReaderWriter,也就是緩衝類也具有可讀寫性，以方便比對。同時還有一個Cache屬性，這就是記憶體地區：映射、儲存下位機的變數。

因為下位機可能有很多個，儲存地址也是不連續的；但通過對下位機地址DeviceAddress的排序，最終下位機地址映射到一塊連續的記憶體位址，通過DeviceAddress的CacheIndex（緩衝索引）相關聯。

每次輪詢，即調用IReaderWriter的ReadBytes方法依次讀入下位機變數地區；讀入的值與Cache中緩衝的資料比對； 所有變化的部分加入一個ChangedList表，儲存變化的CacheIndex。

這些功能在PLCGroup定時器內的Poll函數實現。      

 protected void timer_Timer(object sender, EventArgs e)        {            if (_isActive)            {                lock (sync)                {                    Poll();                    if (_changedList.Count > 0)                        Update();                }            }            else return; }

比較之後，如發現ChangedList的數量大於0，說明有變數數值更新，執行Update方法，根據CacheIndex找到所有變化的變數，通過IGroup 介面的DataChange事件打包推送出去。

具體的訂閱-推送過程，是利用通訊端（Socket）在DAService類實現的。通訊端顧名思義，就是一條電話線：各用戶端向閘道伺服器發送請求，建立一個長串連：只要客戶不掛電話，就一直連著。客戶始終監聽電話；只要伺服器資料有變化，立馬有話務員及時告知，客戶響應。在這裡我實現了一個自訂的TLV（Type-Length-Value）協議，將變化的資料打包發送，用戶端拆包，分解出變數的ID、即時值、時間戳記等資訊，並轉換為圖元的動畫，後文再詳細闡述。

• 上下位機通訊流程圖：

 五、   下面的計劃

 

寫一系列文章，把架構、原理講清楚。大致如下：

• 網關層介面概述
• 上下位機通訊原理
• 如何?一個裝置驅動
• 如何設計圖元
• VS外掛程式模組及原理
• 歸檔模組及檔案格式
• 如何進行功能擴充
• 組態Variant 運算式實現

github地址：https://github.com/GavinYellow/SharpSCADA。QQ群：102486275

開源純C#工控網關+組態軟體(四)上下位機通訊原理