开源纯C#工控网关+组态软件(四)上下位机通讯原理
一、???網關的功能：承上啟下
最近有點忙，更新慢了。感謝園友們給予的支持，現在github上已經有。目標是最好的開源組態，看來又近一步^^
之前有提到網關是物聯網的關鍵環節，它的作用就是承上啟下。
下位機有下位機的語言，上位機有上位機的思路。網關就是一個翻譯，把下位機的語言轉成通用語，再告訴上位機該怎么做。
這個翻譯的過程，應該保證：
實時性。如果太慢，上下位機明顯不合拍，就會出問題。
精確性。信號不能頻繁丟失、丟步、跳步；不能有太大誤差；也不會帶入太多干擾和噪音。
穩定性。如發生故障，如通訊斷開，要能自動重連；要足夠強壯，不會動輒崩潰；發生意外崩潰，要能自動重啟；要有容錯機制和錯誤日志；等等。
要實現這些指標，還是很有挑戰的。
二、???通訊藍本：OPC規范
網關看上去是個很玄奧的東西，網上找來很多相關資料，發現都集中到一個點：OPC規范。
OPC就如一盞明燈，照亮了前進的方向。OPC規范是大家手筆，集中了業界專家的智慧，站在巨人的肩膀上，可以少走很多彎路。
OPC規范定義了數據的采集、歸檔、報警以及完整的接口示范。
OPC數據采集規范，包含了這樣一些重要概念：
數據讀寫方式包括下位機批量推送數據、上位機單獨讀寫數據。
可以異步讀寫，也可以同步讀寫。
數據包括元數據（數據的屬性，如數據類型、長度、名稱等）和過程數據（ID、數值、時間戳、質量戳）。
包含驅動(Driver)-組（Group）-變量（Item）的三級架構。可以對變量按需分組，有的組只讀，有的組需要1秒刷新一次，有的只要5分鐘就可以，要加以區別以提高效率。
要能判斷驅動程序是否斷線、要提供斷線或關閉的事件供應用程序處理。
??
總之，信息量很豐富，啟發很大，我的網關程序很大程度上都參考了OPC規范。
但是OPC有它固有的缺陷：依賴微軟的COM組件技術，不能跨平臺，同時COM是一種過時的技術，在不同主機上通訊的配置十分繁瑣且不安全。
因此，我改造實現了自己的類OPC服務器。基本通訊過程是：批量輪詢下位機-與上個周期的數據比對-提取變化的數據-批量推送給上位機。
三、???與下位機通訊：批量輪詢
-
下位機的特點-為什么要采用輪詢
下位機通訊的特點：
下位機很多采用主-從模式。即主機發送的信息可以傳送到各個從機或指定的從機,而各個從機的信息只能發送給主機。主機采用查詢方式接收發送數據,從機采用中斷方式接收發送數據。這種模式天然適合輪詢。
下位機多數只有一個通信口，有些還是串口，天然不適合推送模式。
下位機很多是單片機，訂閱-發布模式往往邏輯較為復雜，程序編寫難度大，對芯片及存儲要求也必然提高。因此采用這種模式的下位機目前極少。
輪詢就是網關作為主機，定期請求下位機的數據。如果實現批量請求，減少往返，輪詢的效率并不低。幾千個變量輪詢周期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）數據。
未來考慮制定一個新的接口支持這一模式。
四、???與上位機通訊：訂閱-推送
-
?上位機的特點-為什么要采用訂閱-推送
上位機通信的特點主要為：
要及時、準確了解下位機的消息。無論是監控畫面、還是報警、提示人工操作這些，越實時越好，越準確越好。如果采用請求-響應模式，請求的周期決定實時性不會太好。請求頻繁網關壓力大，反之實時性差。
一個網關可能要拖好幾個上位機，工段多的，可能要開十幾個顯示屏同時監控。因此，每個上位機都向網關請求數據，流量會陡然上升，網絡會阻塞，網關壓力會很大。
大部分上位機需要的數據不會經常變化，尤其是一些開關量。如果每次反復請求，浪費資源，浪費時間。
如果采用對各變量單獨請求數據，勢必造成大量不同時段請求-響應過程交錯發生，難以整合，也難以批量讀寫，效率極低。
因此，向訂閱客戶只推送變化的數據，無疑是一種高效的辦法。只要數據發生變化，馬上推送給客戶端，既保證了實時性，又保證了推送數據的最小化。
就像打報修電話，送修單位（下位機）不一定時時刻刻有人上門；電話打過去，總臺（網關）記下號碼，有人上門（下位機有數據變化）了通知（推送）您。沒人你也不用幾秒鐘打一個催（輪詢），你煩大家煩。
-
如何實現訂閱-推送
推送是只推送變化的變量。要知道哪些變量變化了，必須要緩存上一次變量的數據加以比對。因此，需要緩存每次輪詢的數據。
網關在對下位機的輪詢過程中，將訂閱的變量都掃描了一遍；這些數據都存在內存的變量緩存：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插件模塊及原理
-
歸檔模塊及文件格式
-
如何進行功能擴展
-
組態變量表達式實現
github地址：https://github.com/GavinYellow/SharpSCADA。QQ群：102486275
相關文章：?
-
.NET十年回顧
-
開源純C#工控網關+組態軟件
-
開源純C#工控網關+組態軟件(三)加入一個新驅動：西門子S7
原文地址：http://www.cnblogs.com/evilcat/p/7743970.html
.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注
總結
以上是生活随笔為你收集整理的开源纯C#工控网关+组态软件(四)上下位机通讯原理的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： ASP.NET Core 2.0 + E
- 下一篇： 微软Tech Summit 2017，等