开源纯C#工控网关+组态软件(四)上下位机通讯原理

一、   网关的功能:承上启下

最近有点忙,更新慢了。感谢园友们给予的支持,现在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属性,这就是内存区域:映射、储存下位机的变量。

根据下位机的地址最小单元、字节序的不同,对应的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 > 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

posted on 2017-10-28 09:06 老坏猫 阅读(...) 评论(...) 编辑 收藏

导航

统计

公告