不知道什么时候物联网、大数据、云计算……等待大量概念词流行起来，占据主要地位 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实例进行管理。
框架平台一大特点就是开发一套设备驱动（插件）同时支持串口和网络两种通讯方式，而两种通讯方式的切换只需要改动配制文件。
不同的设备类型和协议、不同的通讯方式，用堆代码的方式进行开发，根本无法适应不同场景的应用，提高了代码的维护成本，以及修改代码可能造成潜在的BUG，是让人很头疼的一件事。
在开始设计框架平台的时候，一个核心的思想就是把变的东西要设计灵活，把不变的东西设计稳定。对于设备的协议就是变的东西，对于IO部分就是相对不变的东西，那就需要对串口IO和网络IO进行整合。不仅在代码层面要运行稳定；在逻辑层面，不管是串口IO还是网络IO在框架内部是统一的接口，所有对IO的操作都会通过这个统一的接口来完成。
示意如下图：
多包发送数据是应用环境中的一种情况或一个问题，并不是我们会这样实际应用，而是说在接收过程中多次接收数据才能完整接收客户端一次发送的数据，可能由于网络环境或发送数据端造成的，示意如下图：
例如实时数据的完整包为：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。
在通讯领域中是经常会遇到的问题。也就是多包数据一次性的接收，那么就要合理的进行拆包。还有一种情况，就是多包半的数据一次性的接收，那半包的数据结合“1.一包多发及解决”来解决这个问题，示意如下图：
受电缆或环境的电磁干扰，以及接头虚接等，这种情况极有可能出现。如果干扰的冗余数据夹杂在一个协议包中间，那么校验出合法的数据很困难。如果干扰的冗余数据夹杂在两个协议包中间，那么就可以通过协议过滤来实现识别出有用的数据。示意如下图：
综合解决上述问题，ServerSuperIO支持5种数据过滤器：
FixedEndReceiveFliter：固定结尾的协议过滤器。
FixedHeadAndEndReceiveFliter：固定开头和结尾的协议过滤器。
FixedHeadAndLengthReceiveFliter：固定开头和长度的协议过滤器。
FixedHeadReceiveFliter：固定开头的协议过滤器。
FixedLengthReceiveFliter：固定长度的协议过滤器。
这5个过滤器都继承自IReceiveFilter接口，也可以继承这个接口进行二次开发，定制自己的协议过滤器。代码工程如下图：
物联网建设中数据采集是基础，进行控制是目的，这是两个根本要素。在采集设备数据的时候，如果该设备的实时数据出现异常，那么是否存在其他设备要进行联动？也就是说一个设备出现异常之后，要对其他某个设备进行联动控制，以达到避免出现更大危险的情况。
那么不仅要对某个设备进行联动控制，还要对控制的结果进行反馈给出现异常的设备。形成异常、联动、控制、反馈的闭环，以达到监测与控制共同作用的目的。
如果单单是采集硬件的数据与控制，也只能算是本地的系统，但是在物联网和集成系统建设中，必须形成体系化、网络化框架。所以ServerSuperIO在采集本范围内的数据信息与控制外，还要形成与上一级的ServerSuperIO进行数据交互，以及接收下一级的ServerSuperIO的交互数据，那么ServerSuperIO之间就形成了级联的关系，主要完成两大职责：数据的级联上传和反向控制，进而对设备本身进行级联控制。
结构示意图如下：
采集与控制单个设备，在实际应用中还远远不够，还要能够设备与设备之间进行信息传递与控制，并且返回给发送控制源设备确认信息。例如：在监测流量计严重报警的情况下，是否应该调节或控制液体源头的阀门。类似的例子很多。
ServerSuperIO支持设备向另一个设备发起传递信息和控制后，被控制设备是否立即返回确认信息，还是自主异步决定返回确认信息。增加了异步返回确认信息的功能，因为控制命令只是发给了另一个设备驱动，设备驱动还会进一步与实际的硬件设备进行交互，与实现硬件交互成功后，再返回确认信息给发起的源设备驱动。
示意图如下：
ServerSuperIO提供了服务驱动的接口，一些除设备驱动类的功能以外，都可以以服务驱动的方式存在，例如：多设备采集的数据的融合模型计算、与其他平台或上层进行交互等等，在此仅以与服务端进行交互为实例进行介绍。与设备驱动之间的交互与控制不同的是，设备驱动主动把采集的数据信息传递给服务驱动，服务驱动与云端进行交互，在接收云端指令后，发起传递信息或控制设备驱动，设备驱动再返回确认信息给服务驱动。
示意图如下：
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 年多的时间。对于软件从业人员来讲，还是要沉下心来。
作者 | 王强，有10年工业领域开发和管理经验，在煤炭行业、电力行业、环保和节能行业、冶金行业等多家工业和IT企业从事过开发技术与管理工作；对物联网和系统集成系统产品有丰富理论知识和行业背景经验；开发工作一直使用C#为主，现在从事工业领域大数据平台的建设工作。