概述
不知从何时起，物联网、大数据、云计算……等一大批概念词汇流行起来，占领着各大 IT 网站。不能把这三个语汇独立来看，而是现实系统体系化建设的三个方面。物联网以智能传感器为基础的网络化建设，对大量传感器的实时感知和控制必然会产生大量的数据，而对特定行业的这些数据集合进行数学模型分析必然会产生具有现实的价值。
一个体系三个方面
大公司都在争夺制高点，大数据、云服务、各种标准……，做这些事情都很有意义。在大家都去占领大脑的时候，难道脚就不重要了嘛？显然不是，应该是同等重要。不少公司对于基础物联网建设也是很头痛的一件事，这是系统体系化建设的根基，特别是工业领域。所以针对现阶段物联网建设中高可用、高扩展性通讯框架的应用有很大现实意义和发展空间。
认清物联网建设困难的前提是对现实世界的认知，有些特定行业都根本不具备物联的基础条件，也更谈不上物联网建设，相反也证明物联网的发展会有广阔的市场空间；也有很多具备物联网建设的基础，但是条件比较落后，底子比较薄，现实面临四个多样性的困难：设备多样性、协议多样性、通讯机制多样性、数据多样性。这就是我们面临的问题，但是面对结构化的多样性问题，要用结构化的手段或框架来解决，这是各方面得到保障的前提。
四个多样性
大公司都在搞云平台、协议标准……，当然其有资本和实力，对于他们来说，养这么多人，反而成本是最低的。他们奉行一流企业定标准，用这种思维模式去整合资源，竞争比的就是占领资源的多少。我们认真考虑一下，对于传统企业来讲，生存本来就很困难，他们有能力在很短的时间内完全统一更新换代嘛？！参加上海工业博览会，也进行了市场调查，这是不现实的。我们再认真考虑一下，用框架性的东西去解决设备多样性、协议多样性、通讯机制多样性、数据多样性的问题，在物联网和集成系统的建设中是否也是整合资源的一种手段？先解决企业互联监控的问题，再解决企业标准化的问题，这样是否也是一种思维模式？是的，我们就先这样干！
不同方式的整合资源
曾接触过上海一家公司，有专人负责网关层的数据采集，有专人负责服务（云）端的对接，不太稳定、经常出现问题。解决细节问题，不能用细节的思维方式去解决，而是要有更广阔的思维、结构化思路才能够彻底的、更好的解决问题。网关层、服务端是否可以使用同一套框架？并且框架之间是否可以无缝对接？如果可以实现，应用同一套框架，开发效率会提高，用人成本和时间成本会降低。好的组织结构、好的框架要解决效率和成本的问题，否则没有任何价值。
降本增效
ServerSuperIO就是以这样的一种思维方式演变而来，ServerSuperIO不仅仅是通讯框架，否则它和任何其他的通讯框架没有任何区别，也不具备现实意义。ServerSuperIO是一个物联网框架，首先是以设备（传感器）为核心构建的框架，设备（传感器）的协议无关性，可以随意挂载设备驱动在框架下运行。所以ServerSuperIO本质上协调设备驱动（协议）、IO通道（COM和NET）、运行机制（模式）之间的协调机制，使之无缝结合、运行。框架具备如下特点：
轻型高性能通信框架，适用多种应用场：轮询模式、自控模式、并发模式和单例模式。
支持协议驱动器，可以按规范写标准协议和自定义协议。
支持发送数据缓存器，支持命令缓存重发和按优先级别发送。
支持协议过滤器，按规则筛选数据，并且可以承继接口，自定义过滤方式。
支持接收数据缓存器，可以缓存不符合过滤器的数据，和下次接收数据进行拼接。
支持按设备命令优先级别进行调度设备，保证有高级别命令的驱动及时发送。
支持一个设备驱动，同时支持串口和网络两种通讯方式，可以监视IO通道数据。
支持一个设备驱动，在网络通讯时可以支持TCP Server和TCP Client两种工作模式。
支持多设备共享同一IO通道进行通讯。
支持定时清理超时的网络IO通道。
支持显示视图接口，满足不同人机对话的需求。
支持服务组件接口，例如：4-20mA输出、LED大屏显示、短信服务、以及多功能网关服务。
设备驱动与设备驱动，设备驱动与服务器（云端）可以实时双向交互，上传数据和指令下发。
支持OPC Server服务。
支持创建多服务实例，完成不同业务的拆分。
支持跨平台部署，可以运行在Linux和Windows系统。
通讯机制
有些网友认为通讯很简单，打开连接之后发送、接收数据就可以了。但是把复杂的情况考虑全面，并非易事。对于实时数据采集框架，通讯部分始终是软件的核心，要求高实时性、高稳定性、高扩展性。软件框架决定了软件运行的稳定性，以及以后的扩展性，所以需要对通讯机制、控制方式进行良好的设计。
所以决定了软件框架在通讯方面有两种应用方式：主动请求和被动接收。
主动请求方式又可以称之为呼叫应答方式或主从方式。也就是说，主动权在软件框架端，只有软件框架主动发送请求命令，从机（硬件设备、传感器等）接收到命令后并且检验数据的完整性，以及确定是否发给自己的命令，校验成功后，返回指定的数据信息，完成一次完整的链路通讯过程。呼叫应答通讯方式，如图5所示：
呼叫应答通讯方式
被动接收方式是软件框架实时监测IO通道，只要有数据信息就会提取出来，进行数据校验，检验成功后，分析、处理、保存数据信息。例如设备、传感器等定时发送状态数据。这种通讯方式，如下图：
被动接收方式
在复杂的应用场景中，这两种通讯方式都有可能存在，此类情况一般是采用以太网链路进行通讯。针对只有外接串口的设备可以通过以太网转换模块来接入。
轮询通讯机制
这是框架最早的运行模式，串口和网络通讯时都可以使用这种控制模式。当有多个设备 连接到通讯平台时，通讯平台会轮询调度设备进行通讯任务。某一时刻只能有一个设备发送请求命令、等待接收返回数据，这个设备完成发送、接收（如果遇到超时
情况，则自动返回）后，下一个设备才进行通讯任务，依次轮询设备。
应用场景是这样的，服务端与设备进行通讯遵循呼叫应答的方式，也就是IO可用的情况下，服务端先发起通讯命令请求，设备根据命令信息，检验通过后返回数据给服务端。这种通讯模式很好理解，每个设备的通讯都遵循排队的原则。但是如果某个设备的命令需要及时发送，怎么办？ServerSuperIO框架是支持设备优先级别调度的，例如：对某个设备要进行实时的检测，需要连续发送命令，那么就需要对设备进行高级别设置，发送请求数据命令。
通讯结构如下图：
并发通讯机制
网络通讯的情况下，轮询模式显然效率比较低，那么可以采用并发模式。并发通讯模式是集中发送给所有设备请求指令，框架是采用循环同步方式发送请求命令给每个IO通道对应的设备，当然也可以采用并行异步方式集中发送请求命令。硬件设备接收到指令后进行校验，校验成功后返回对应指令的数据，通讯平台异步监听到数据信息后，进行接收操作，然后再进行数据的分发、处理等。
那么这里就涉及到IO通道接收到的数据是异步接收的，如何才能和设备驱动匹配上（把数据分发到设备驱动上），这是能过DeviceCode和DeviceIP两种方式来实现的。DeviceCode可以是设备地址或是设备编码，DeviceIP是预先设置好的参数，要求终端设备的IP地址是固定的。
通讯结构如下图：
自控通讯机制
只有网络通讯时可以使用这种控制模式。自控通讯模式与并发通讯模式类似，区别在于发送指令操作交给设备驱动本身进行控制，或者说交给二次开发者，二次开发者可以通过时钟定时用事件驱动的方式发送指令数据。硬件设
备接收到指令后进行校验，校验成功后返回对应指令的数据，通讯平台异步监听到数据信息后，进行接收操作，然后再进行数据的分发、处理等。
自控通讯模式可以为二次开发者提供精确的定时请求实时数据机制，使通讯机制更灵活、自主，如果多个设备驱动共享使用同一个IO通道的话，时间控制会有偏差。
同样涉及到数据的分发，和并发模式一样。
通讯结构如下图：
单例通讯机制
只有网络通讯时可以使用这种控制模式。在一个服务实例内只能有一个设备驱动，相当于一个设备驱动对应着N多个硬件设备终端。更适合通讯的数据协议有固定的标准，以命令关键字处理不同的数据。适用于高并发的硬件终端设备主动上传数据，服务器端根据数据信息进行处理和返回相应的数据。
通讯结构如下图：
“传感器”驱动的插件化应用
插件技术是在软件的设计和开发过程中，将整个应用程序划分为宿主程序和插件对象两部分，宿主程序能够调用插件对象，插件对象能够在宿主程序上实现自己的逻辑，而两者的交互基于一种公共的通信契约。宿主程序可以独立于插件对象存在，即使没有任何插件对象，宿主程序的运行也不受影响，因此，我们可以在避免改变宿主程序的情况下通过增减插件或修改插件的方式增加或调整功能。由于使用了插件技术的宿主程序具备了一个框架的本质特征，因此可以将它看作是一种插件式框架。插件式框架能够有效地降低功能对象与对象管理逻辑之间的耦合程度，并将耦合置于最优的程度。
一个框架使用插件机制的原因主要基于以下3点：
可以在无需对程序进行重新编译和发布的条件下扩展程序的功能。
可以在不需要程序源代码的环境下为程序增加新的功能。
在一个程序的业务逻辑不断发生改变、新的规则频频加入时能够灵活适应。
实现插件机制一般有3种技术：基于动态连接库DLL的插件、基于组件对象模型COM的插件、以及基于.NET反射技术的插件。ServerSuperIO是使用.NET反射技术实现的插件机制。
插件式框架的宿主程序启动后，它首先会加载相应的配置文件（例如：设备驱动配置文件等），找到相应的插件程序集，这些程序集以DLL文件格式存在，框架的宿主程序会找到指定的插件类型，由插件引擎依据插件类型（例如：IRunDevice）生成对象实例，由框架的宿主程序的管理器对插件实例进行管理和调度。
一个插件程序集可能包括多个插件类型，那么框架宿主程序是如何识别这些类型是否为要加载的插件呢？每个插件对象都有一个身份标识－接口，这个标识在框架设计中被称为“通讯契约”。接口可以被看作是一种定义了必要的方法、属性和事件的集合，因此宿主程序就可以通过这种契约来生成具体的实例对象，并对其他组件或接口公开可操作的对象。
插件式框架作为一个高聚合低耦合的平台，它的功能定义与功能实现之间是分离的。只要符合插件规范的二次开发组件都可以挂载到框架平台中，而它并不关心这些组件的具体功能。当然，框架平台提供了一些必要的信息、机制来保证这些组件能够正常实现二次开发的功能。
在具有多个逻辑层次的结构设计中，各层之间的通信大多通过接口来实现，接口不会轻易改变，如果一个层的功能发生变化，不会影响其他层；只要正常实现了接口的组件功能，那么程序的运行就没有问题。这种做法使得各层之间的相互影响降低到最低，总之，接口在多业务层级中能够更好的解耦，所以每个设备驱动都可以有自己的业务逻辑。
可挂载的设备驱动信息在配置文件中进行标注，当挂载新的设备驱动的时候，如增加设备，就会从这个配置组中加载信息，以便操作人员进行选择。设备驱动配置信息定义如下图：
当调用增加设备驱动窗体的时候会从配置文件读取程序集信息，以完成增加设备驱动，并且在ServerSuperIO框架下运行。
一套驱动同时支持多种IO链路
作为物联网通讯框架平台软件，IO是核心部分之一，涉及到与硬件设备、软件之间的信息数据交互，主要包括两部分：IO实例与IO管理器。IO实例负责直接对串口和网络进行操作；IO管理器负责对IO实例进行管理。
框架平台一大特点就是开发一套设备驱动（插件）同时支持串口和网络两种通讯方式，而两种通讯方式的切换只需要改动配制文件。
不同的设备类型和协议、不同的通讯方式，用堆代码的方式进行开发，根本无法适应不同场景的应用，提高了代码的维护成本，以及修改代码可能造成潜在的BUG，是让人很头疼的一件事。
在开始设计框架平台的时候，一个核心的思想就是把变的东西要设计灵活，把不变的东西设计稳定。对于设备的协议就是变的东西，对于IO部分就是相对不变的东西，那就需要对串口IO和网络IO进行整合。不仅在代码层面要运行稳定；在逻辑层面，不管是串口IO还是网络IO在框架内部是统一的接口，所有对IO的操作都会通过这个统一的接口来完成。
示意如下图：
数据过滤器，解决一包多发、粘包、冗余数据
（1）一包多发及解决
多包发送数据是应用环境中的一种情况或一个问题，并不是我们会这样实际应用，而是说在接收过程中多次接收数据才能完整接收客户端一次发送的数据，可能由于网络环境或发送数据端造成的，示意如下图：
例如实时数据的完整包为：55 AA 00 61 43 7A 00 00 43 B4 15 0D。那么接收数据的时候，第一次接收到：55
AA 00 61 43 7A 00 00 43 B4 15，第二次接到：0D。按通讯协议应该能够把这两次接收的数据进行自动拼接，形成完整的数据并进行解析2。
（2）粘包及解决
在通讯领域中是经常会遇到的问题。也就是多包数据一次性的接收，那么就要合理的进行拆包。还有一种情况，就是多包半的数据一次性的接收，那半包的数据结合“1.一包多发及解决”来解决这个问题，示意如下图：
（3）冗余数据的出现及解决
受电缆或环境的电磁干扰，以及接头虚接等，这种情况极有可能出现。如果干扰的冗余数据夹杂在一个协议包中间，那么校验出合法的数据很困难。如果干扰的冗余数据夹杂在两个协议包中间，那么就可以通过协议过滤来实现识别出有用的数据。示意如下图：
综合解决上述问题，ServerSuperIO支持5种数据过滤器：
FixedEndReceiveFliter：固定结尾的协议过滤器。
FixedHeadAndEndReceiveFliter：固定开头和结尾的协议过滤器。
FixedHeadAndLengthReceiveFliter：固定开头和长度的协议过滤器。
FixedHeadReceiveFliter：固定开头的协议过滤器。
FixedLengthReceiveFliter：固定长度的协议过滤器。
这5个过滤器都继承自IReceiveFilter接口，也可以继承这个接口进行二次开发，定制自己的协议过滤器。代码工程如下图：
传感器之间、传感器与云端的交互
物联网建设中数据采集是基础，进行控制是目的，这是两个根本要素。在采集设备数据的时候，如果该设备的实时数据出现异常，那么是否存在其他设备要进行联动？也就是说一个设备出现异常之后，要对其他某个设备进行联动控制，以达到避免出现更大危险的情况。
那么不仅要对某个设备进行联动控制，还要对控制的结果进行反馈给出现异常的设备。形成异常、联动、控制、反馈的闭环，以达到监测与控制共同作用的目的。
如果单单是采集硬件的数据与控制，也只能算是本地的系统，但是在物联网和集成系统建设中，必须形成体系化、网络化框架。所以ServerSuperIO在采集本范围内的数据信息与控制外，还要形成与上一级的ServerSuperIO进行数据交互，以及接收下一级的ServerSuperIO的交互数据，那么ServerSuperIO之间就形成了级联的关系，主要完成两大职责：数据的级联上传和反向控制，进而对设备本身进行级联控制。
结构示意图如下：
（1）传感器之间的交互、控制
采集与控制单个设备，在实际应用中还远远不够，还要能够设备与设备之间进行信息传递与控制，并且返回给发送控制源设备确认信息。例如：在监测流量计严重报警的情况下，是否应该调节或控制液体源头的阀门。类似的例子很多。
ServerSuperIO支持设备向另一个设备发起传递信息和控制后，被控制设备是否立即返回确认信息，还是自主异步决定返回确认信息。增加了异步返回确认信息的功能，因为控制命令只是发给了另一个设备驱动，设备驱动还会进一步与实际的硬件设备进行交互，与实现硬件交互成功后，再返回确认信息给发起的源设备驱动。
示意图如下：
（2）传感器与云端的交互、控制
ServerSuperIO提供了服务驱动的接口，一些除设备驱动类的功能以外，都可以以服务驱动的方式存在，例如：多设备采集的数据的融合模型计算、与其他平台或上层进行交互等等，在此仅以与服务端进行交互为实例进行介绍。与设备驱动之间的交互与控制不同的是，设备驱动主动把采集的数据信息传递给服务驱动，服务驱动与云端进行交互，在接收云端指令后，发起传递信息或控制设备驱动，设备驱动再返回确认信息给服务驱动。
示意图如下：
与OPC Server的对接
OPC(OLE for Process Control, 用于过程控制的OLE)是一个工业标准，基于微软的OLE(现在的Active
X)、COM （部件对象模型）和DCOM （分布式部件对象模型）技术。OPC包括一整套接口、属性和方法的标准集。用于世界上所有主要的自动化控制系统、仪器仪表及过程控制系统的公司。
ServerSuperIO通过加载的设备驱动以网口或串口为通讯链路实时与硬件传感器交互、采集数据信息，设备驱动采集到硬件传感器的数据信息之后立即传递给OPC
Server，OPC Server的数据发生变化后，在OPC Client能够立即做出响应，这样更能体现数据的实时性，避免OPC
Server定时读取数据库的数据信息而造成延迟，也不能及时反应数据变化的真实性。
结构示意如下图：
运行“ServerSuperIO.Tool.exe”工具，单击【标签配置】菜单，把挂载的可运行设备驱动的动态数据接口的属性映射成Tag标签。启动程序后，OPC客户端就可以实时读取到数据信息。如下图：
配置标签
OPC客户端读取数据
与实时数据库的对接
实时数据库系统是开发实时控制系统、数据采集系统等的后台支撑软件。大量使用实时数据库系统进行控制系统监控，系统先进控制和优化控制，并为企业的生产管理和调度、数据分析、决策支持及远程在线浏览提供实时数据服务和多种数据管理功能。实时数据库已经成为企业信息化的基础数据平台，可直接实时采集、获取企业运行过程中的各种数据，并将其转化为对各类业务有效的公共信息，满足企业生产管理、企业过程监控、企业经营管理之间对实时信息完整性、一致性、安全共享的需求，可为企业自动化系统与管理信息系统间建立起信息沟通的桥梁。
实时数据库的一个重要特性就是实时性，包括数据实时性和事务实时性。数据实时性是现场IO数据的更新周期，不能不考虑数据的实时性。一般数据的实时性主要受现场设备的制约，特别是对于一些比较老的系统而言，情况更是这样。事务实时性是指数据库对其事务处理的速度。它可以是事件触发方式或定时触发方式。事件触发是该事件一旦发生可以立刻获得调度，这类事件可以得到立即处理，但是比较消耗系统资源；定时触发是在一定时间范围内获得调度权。
系统框架示意如下图：
ServerSuperIO 作为物联网通讯框架，是系统体系化建设的关键节点，同时也需要后台持久化服务的支持。实时采集传感器的点数据，用实时数据库对采集点数据进行时序存储是最理想的。
通过持久化接口进行存储操作，接口示意如下图：
结构示意如下图：
结束语
最近科技日报发表文章《离开高档工业软件，“中国制造2025”只是梦想》，文章强调：“一硬、一软、一网、一台是制造业的‘新四基’。工业和信息化部副部长怀进鹏如此解释：‘硬’是指自动控制和感知硬件；’软’是指工业核心软件；‘网’是指工业互联网；‘平台’是指工业云和智能服务平台。而在新的模式下，软件成为重要的生产要素；在中国，工业软件的机会和挑战并存。2015
年，中国软件业人均收入 14.1 万元，仅次于金融行业的 14.2 万元。软件从业人员 547 万人，创造了
4.9 万亿元产值; 但是在所有软件人员里面，工业软件从业人员比例极低;我们大部分大学，变成国外软件培训基地，这一点非常悲哀。”
ServerSuperIO 从一开始雏形到现在不断的迭代、完善，已经有 6 年多的时间。对于软件从业人员来讲，还是要沉下心来。
|
