一、 网关的功能：承上启下
最近有点忙，更新慢了。感谢园友们给予的支持，现在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属性，这就是内存区域：映射、储存下位机的变量。
根据下位机的地址最小单元、字节序的不同，对应的ICache也相应不同。例如ModbusTcp是16位寄存器，网络字节序，相应的Cache也是16位数组，按照网络字节序读写；AB PLC对应的Cache则是32位数组。
因为下位机可能有很多个，存储地址也是不连续的；但通过对下位机地址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 > )
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