不管是zigbee、wifi、有线网络，还是RS485、RS232、RS422，总之主要分为两种硬件接口：网口和串口。至于OPC协议，可以用SSIO服务接口的形成间接实现，形成服务插件的一部分。如果不结构化的设计IO，网口和串口独立存在，随着产品越来越多，是很头痛的一件事，也不一定运行稳定。对于ServerSuperIO框架，在此基础上开发一套设备驱动可以分别实现通过网口或串口与硬件设备（传感器）进行交互，非常方便。有人认为通讯很简单，其实如果把众多问题都考虑进去，那么将变得很复杂。也有很多纯网络通讯框架，业务场景、通讯机制的不同，纯网络通讯框架也未必能够完全的适用于现场环境。根据多年的工作经验，针对SSIO增加了通讯机制与应用场景，参见：《连载 | 物联网框架ServerSuperIO教程》1.4种通讯模式机制。

     示意图如下：

8.一套设备驱动，统一接口，多种平台挂载运行

     针对ServerSuperIO框架的设备驱动接口进行标准化设计，另外针对ServerSuperIO框架本身进行了跨平台运行的移植工作，所以一次开发设备驱动，可以在多种平台下挂载运行。现在支持的平台包括：Windows xp SP3以上的版本操作系统（包括Server）、Windows 10 IOT嵌入式操作系统、Ubuntu&Ubuntu Mate操作系统。

     示意图如下：

9.物联通讯的级联

      如果单单是采集硬件的数据与控制，也只能算是本地的系统，但是在物联网和集成系统建设中，必须形成体系化、网络化框架。所以ServerSuperIO在采集本范围内的数据信息与控制外，还要形成与上一级的ServerSuperIO进行数据交互，以及接收下一级的ServerSuperIO的交互数据，那么ServerSuperIO之间就形成了级联的关系，主要完成两大职责：数据的级联上传和反向控制，进而对设备本身进行级联控制。

      结构示意图如下：

10.设备之间的通讯、控制

      采集与控制单个设备，在实际应用中还远远不够，还要能够设备与设备之间进行信息传递与控制，并且返回给发送控制源设备确认信息。例如：在监测流量计严重报警的情况下，是否应该调节或控制液体源头的阀门。类似的例子很多。

     在ServerSuperIO最新的3.1版本中（还没有发布），支持设备向另一个设备发起传递信息和控制后，被控制设备是否立即返回确认信息，还是自主异步决定返回确认信息。增加了异步返回确认信息的功能，因为控制命令只是发给了另一个设备驱动，设备驱动还会进一步与实际的硬件设备进行交互，与实现硬件交互成功后，再返回确认信息给发起的源设备驱动。

     示意图如下：

11.与云端的交互、控制

     ServerSuperIO提供了服务驱动的接口，一些除设备驱动类的功能以外，都可以以服务驱动的方式存在，例如：多设备采集的数据的融合模型计算、与其他平台或上层进行交互等等，在此仅以与服务端进行交互为实例进行介绍。与设备驱动之间的交互与控制不同的是，设备驱动主动把采集的数据信息传递给服务驱动，服务驱动与云端进行交互，在接收云端指令后，发起传递信息或控制设备驱动，设备驱动再返回确认信息给服务驱动。

     示意图如下：

12.未来的规划

     从大环境来讲，肯定是有很广泛的应用；从本公司来讲，将来在工业基础物联层面，肯定也会用的上；从个人兴趣来讲，也乐意能够继续做这方面的工作，当然是除正式工作之外。

     从ServerSuperIO本身来讲，3.1版本（未发布）对代码进行优化以及增加了异步返回确认信息的交互能力。后期会增加对数据安全方案的验证机制，以保障在工业领域应用数据交互与控制的安全性。另外从体系结构来讲，以ServerSuperIO框架为基础，增加云端的建设能力，例如：数据分布式持久化等。从嵌入式应用为讲，要增加远程可配置能力等。

13.结束语

     在现在的社会，长期坚持做一件事很不容易，做成产品级以及配合体系方案更不容易。慢慢往下走吧，希望机会会眷顾那些踏实、实干的人。天道酬勤！！！

1.[连载]《C#通讯（串口和网络）框架的设计与实现》

2.[开源]C#跨平台物联网通讯框架ServerSuperIO（SSIO）介绍

2.应用SuperIO（SIO）和开源跨平台物联网框架ServerSuperIO（SSIO）构建系统的整体方案

3.C#工业物联网和集成系统解决方案的技术路线（数据源、数据采集、数据上传与接收、ActiveMQ、Mongodb、WebApi、手机App）

5.ServerSuperIO开源地址：https://github.com/wxzz/ServerSuperIO

物联网&集成技术(.NET) QQ群：54256083 

连载教程：