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

最近有點忙，更新慢了。感謝園友們給予的支持，現在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插件模塊及原理
• 歸檔模塊及文件格式
• 如何進行功能擴展
• 組態變量表達式實現

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

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