[开源]跨平台物联网通讯框架-ServerSuperIO（SSIO）

1.自我介绍

            本人已经工作10年，一直在工业领域。在一线干过实施，下过矿井；干过项目，带过团队；干过软件研发，出过产品；干过项目群管理，售前和市场也接触过；期间在纯软件公司也干过将近两年的时间，熟悉软件开发流程与管理。虽然没有取得多大成绩，也算经历丰富了。

           互联网“行业”如火如荼的发展，曾经也想过转行去做“互联网”，奈何犹豫太久，已然提不起太多兴趣。凭借当年的沉淀与积累，有个半成品的框架，在工作索然无味的情况下，毫不犹豫的投身到物联网框架的开发与产品化的进程中。别人都说物联网的时代来了，如果真的是这样，也不知道是自己的选择好，还是命好。

这方面的工作纯属个人爱好，业余时间在干，一般晚上21点到23点是自己的第二个工作时间。这两年积极的投身到新的框架开发中，提高性能、统一接口、跨平台……等方面的工作。也做了自己的基础硬件产品，智能网关。

          有人会问，那你正式工作是干什么的？在某集团公司工业版块负责大数据建设的相关工作。在没有大数据、云服务概念的时候，做过远程E服务相关的项目。说实话，对于传统行业来讲，是很困难的一件事。但是作为企业来讲，要么等死，要么在改变中死，完全在于自己的选择。

2.占领大脑和丢了脚

         不知道从什么时候，物联网、大数据、云计算……等一批概念流行起来。大厂都在争夺高制高点，大数据、云服务、各种标准……，做这些事情都很有意义。但是我在想，大家都去占领大脑，脚就不重要了嘛？！显然不是，应该是同等重要。华为某部、中兴某仪表……对于基础物联层，也是很头痛的一件事，这是大厦的根基，特别是工业领域。所以，我坚信对于我们的框架有很大的市场应用空间，创造的直接价值那是另外一回事。

3.物联的现实困难

           对困难理解的前提是对现实世界的认知，有些传统制造业都不具备物联的基础条件，更谈不上物联网、智能制造、智能工厂，但是至因为落后，才有广阔的市场空间。就算有物联的基础，条件比较落后，底子比较薄，面临四个多样性：设备多样性、协议多样性、通讯机制多样性、数据多样性。这就是我们面临的问题，难道问题有多大吗？为了生存，企业都说能做。但是结构化的多样性问题，要用结构化的手段或框架来解决，这是各方面保障的前提。

4.效率与成本

            接触一家上海公司，有专人负责网关层的数据采集，有专人负责服务（云）端的对接，不太稳定、经常出现问题。解决细节问题，不能用细节的思维方式去解决，而是要有更广阔的思维、结构化思路才能够彻底的、更好的解决问题。网关层、服务端是否可以使用同一套框架？并且框架之间是否可以无缝对接？如果可以实现，应用同一套框架，开发效率会提高，用人成本和时间成本会降低。好的组织结构、好的框架总之要解决效率和成本，否则没有任何价值。

5.逆向思维

            大厂都在搞云平台、协议标准……，当然他们有资本和实力这样搞，软件用他们的、硬件用他们的，对于他们来讲，养这么多人，反而成本是最低的。他们奉行一流企业定标准，用这种思维模式去整合资源，竞争比的就是占领资源的多少。我们认真考虑一下，对于传统企业来讲，本来生存就很困难，和房地产、互联网拿投资的没法比，他们有能力一下子完全统一化的更新换代嘛？！参加上海工业博览会，也进行了市场调查，简直是开玩笑。我们再认真考虑一下，用框架性的东西去解决设备多样性、协议多样性、通讯机制多样性、数据多样性的问题，在物联网和集成系统的建设中是否也是整合资源的一种手段？！先解决企业互联监控的问题，再解决企业标准化的问题，这样是否也是一种思维模式？！是的，我们就先这样干！

        6.发展历程

            SuperIO&ServerSuperIO最早的雏形于2010年开始开发，当时主要是解决公司内部硬件产品众多、协议众多、以前的软件经常出问题、维护成本高、搞集成系统时各方面都很累。经过两三年的发展，确实解决了公司内部的产品体系问题，所有硬件产品都可以挂载到平台下运行。离开公司之后，感觉这个平台从代码、应用等方面还有很大发展空间，2014年逐步产品化后才形成了SuperIO（SIO）这个平台。

           但是SIO也只是解决了设备驱动（众多协议）插件式挂载的问题，不过只限于运行在Windows系列操作系统下，一般性的PC机和工控机上数据采集完全没有问题。但是在运行效率方面还有很大提升空间、设备驱动的接口还可以进一步标准化（为了各层级都可以应用）、跨平台运行必须攻克、设备（驱动）之间信息交互与控制必须实现、框架在不同层级应用的级联与控制必须实现、多服务实例的应用等等，一系列的框架和技术性问题还可以进一步完善。从整体物联网建设的框架性方面考虑，从2015年初开始，基于SIO的核心思想重新开发新一代物联网框架，也就是现在的ServerSuperIO（SSIO）框架，经过两年多的发展，搭载在智能网关的基础上，可以形成综合性的解决方案。

          SSIO通信框架的设计思想是在SuperIO（SIO）基础上发展而来，并没有高大上的技术，主要是工作经验的积累，适合于不同应用场景的物联网的数据采集与交互。SSIO和SIO并不是简单的对IO高性能的操作，而是设备驱动、IO通道、控制模式和实际硬件设备之间的协调机制，各方面之间无缝衔接和运行，也是为了解决现实工作和应用场景的一些痛点。

            软硬件之间的数据交互，并且面临着复杂的现场环境：

          （1）复杂的、多样的通讯协议。有标准的协议，例如：Modbus等，也有很多根据标准协议修改的协议格式、以及自定义协议格式，并且千差万别。对于不好的软件架构，疲于应对，增加设备或协议要对整个软件进行梳理，往往在此过程中出现新的问题或BUG。

         （2）针对不同用户对软件界面或功能的要求有很大不同，使之满足不同用户的显示要求，可以自定义数据显示界面。那么就需要提供显示视图接口，与设备驱动进行交互。

         （3）既然现场设备的数据被采集上来，那么就需要对其进行处理，不仅仅是保存、查询、报表等，还有：数据转发、数据输出（OPC、模拟量、大屏等）等。那么就需要提供服务性的接口，与设备驱动进行交互。

        （4）通讯链路的多种性，对于同一个设备可能要支持RS232/RS485/RS422、RJ45、3G/4G等通讯方式，所以对于一个设备要对应多种通讯方式（串口和网络），也给我们的开发造成很大的障碍。

        （5）设备驱动、IO通道和实际的现场硬件终端之间链路复杂，有可能：一个设备驱动对应一个IO通道、一个设备驱动对应多个IO通道、多个设备驱动对应一个IO通道等情况。

        （6）既然设备与服务端进行数据交互，那么就应该对设备的通讯状态、IO状态、以及设备本身的状态进行监控，这样设备才处于可维护状态。

        （7）软件各版本、以及软件与硬件之间的兼容性很差，管理起来错综复杂。在框架平台稳定的情况下，只需要更新设备驱动。

        为了解决以上诸多问题，开发一个软件框架，支持二次开发。在不对软件框架改动的情况下，能够很方便的接入设备、维护设备、集成设备、处理设备业务数据等。软件框架相对稳定，把容易变化的部分进行灵活设计。

          7.框架特点

• 轻型高性能通信框架，适用于多种应用场，轮询模式、自控模式、并发模式和单例模式。
• 不光是通讯框架，是设备驱动、IO通道、控制模式场景的协调机制。
• 支持协议驱动器，可以按规范写标准协议和自定义协议。
• 支持发送数据缓存器，支持命令缓存重发和按优先级别发送。
• 支持协议过滤器，按规则筛选数据，并且可以承继接口，自定义过滤方式。
• 支持接收数据缓存器，可以缓存不符合过滤器的数据，和下次接收数据进行拼接。
• 支持按设备命令优先级别进行调度设备，保证有高级别命令的驱动及时发送。
• 支持一个设备驱动，同时支持串口和网络两种通讯方式，可以监视IO通道数据。
• 支持一个设备驱动，在网络通讯时可以支持TCP Server和TCP Client两种工作模式。
• 支持多设备共享同一IO通道进行通讯。
• 支持定时清理超时的网络IO通道。
• 支持显示视图接口，满足不同显示需求。
• 支持服务组件接口，4-20mA输出、LED大屏显示、短信服务、以及多功能网关服务。
• 支持OPC Server服务。
• 支持创建多服务实例，完成不同业务的拆分。
• 支持跨平台部署，可以运行在Linux和Windows系统。
• 设备驱动与设备驱动，设备驱动与服务器（云端）可以实时双向交互，上传数据和指令下发。
  

8.一套设备驱动，支持多种IO通讯

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

           示意图如下：

        

9.物联通讯的级联

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

           结构示意图如下：

 

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

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

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

           示意图如下：

 

11.与云端的交互、控制

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

            示意图如下：

 

      12.控制模式

         （1）轮询模式：当串口和网络通讯时都可以使用这种控制模式。当有多个设备连接到通讯平台时，通讯平台会轮询调度设备进行通讯任务。某一时刻只能有一个设备发送请求命令、等待接收返回数据，这个设备完成发送、接收（如果遇到超时情况，则自动返回）后，下一个设备才进行通讯任务，依次轮询设备。如下图：

 

         （2）并发模式：只有网络通讯时可以使用这种控制模式。并发通讯模式是集中发送所有设备的请求指令，框架是采用循环同步方式发送请求命令。还有进一步提高的机会，采用并行异步方式集中发送请求命令。硬件设备接收到指令后进行校验，校验成功后返回对应指令的数据，通讯平台异步监听到数据信息后，进行接收操作，然后再进行数据的分发、处理等。如下图：

 

        （3）自控模式：只有网络通讯时可以使用这种控制模式。自控通讯模式与并发通讯模式类似，区别在于发送指令操作交给设备驱动本身进行控制，或者说交给二次开发者，二次开发者可以通过时钟定时用事件驱动的方式发送指令数据。硬件设备接收到指令后进行校验，校验成功后返回对应指令的数据，通讯平台异步监听到数据信息后，进行接收操作，然后再进行数据的分发、处理等。

         自控通讯模式可以为二次开发者提供精确的定时请求实时数据机制，使通讯机制更灵活、自主，如果多个设备驱动使用同一个IO通道的话，时间控制会有偏差。如下图：

 

         （4）单例模式：只有网络通讯时可以使用这种控制模式。在一个服务实例内只能有一个设备驱动，相当于一个设备驱动对应着N多个硬件设备终端。更适合通讯的数据协议有固定的标准，以命令关键字处理不同的数据。适用于高并发的硬件终端设备主动上传数据，服务器端根据数据信息进行处理和返回相应的数据。如下图：

 

            13.跨平台

                   （1）Windows运行效果

 

                   （2）Linux运行效果

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

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