本篇内容主要讲解“ServerSuperIO的相关知识点有哪些”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“ServerSuperIO的相关知识点有哪些”吧!
发展历程
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）软件各版本、以及软件与硬件之间的兼容性很差，管理起来错综复杂。在框架平台稳定的情况下，只需要更新设备驱动。
为了解决以上诸多问题，开发一个软件框架，支持二次开发。在不对软件框架改动的情况下，能够很方便的接入设备、维护设备、集成设备、处理设备业务数据等。软件框架相对稳定，把容易变化的部分进行灵活设计。
框架特点
轻型高性能通信框架，适用于多种应用场，轮询模式、自控模式、并发模式和单例模式。
不光是通讯框架，是设备驱动、IO通道、控制模式场景的协调机制。
支持协议驱动器，可以按规范写标准协议和自定义协议。
支持发送数据缓存器，支持命令缓存重发和按优先级别发送。
支持协议过滤器，按规则筛选数据，并且可以承继接口，自定义过滤方式。
支持接收数据缓存器，可以缓存不符合过滤器的数据，和下次接收数据进行拼接。
支持按设备命令优先级别进行调度设备，保证有高级别命令的驱动及时发送。
支持一个设备驱动，同时支持串口和网络两种通讯方式，可以监视IO通道数据。
支持一个设备驱动，在网络通讯时可以支持TCP Server和TCP Client两种工作模式。
支持多设备共享同一IO通道进行通讯。
支持定时清理超时的网络IO通道。
支持显示视图接口，满足不同显示需求。
支持服务组件接口，4-20mA输出、LED大屏显示、短信服务、以及多功能网关服务。
支持OPC Server服务。
支持创建多服务实例，完成不同业务的拆分。
支持跨平台部署，可以运行在Linux和Windows系统。
设备驱动与设备驱动，设备驱动与服务器（云端）可以实时双向交互，上传数据和指令下发。
一套设备驱动，支持多种IO通讯
不管是zigbee、wifi、有线网络，还是RS485、RS232、RS422，总之主要分为两种硬件接口：网口和串口。至于OPC协议，可以用SSIO服务接口的形成间接实现，形成服务插件的一部分。如果不结构化的设计IO，网口和串口独立存在，随着产品越来越多，是很头痛的一件事，也不一定运行稳定。对于ServerSuperIO框架，在此基础上开发一套设备驱动可以分别实现通过网口或串口与硬件设备（传感器）进行交互，非常方便。有人认为通讯很简单，其实如果把众多问题都考虑进去，那么将变得很复杂。也有很多纯网络通讯框架，业务场景、通讯机制的不同，纯网络通讯框架也未必能够完全的适用于现场环境。根据多年的工作经验，针对SSIO增加了通讯机制与应用场景，参见：《连载 | 物联网框架ServerSuperIO教程》1.4种通讯模式机制。
示意图如下：
物联通讯的级联
如果单单是采集硬件的数据与控制，也只能算是本地的系统，但是在物联网和集成系统建设中，必须形成体系化、网络化框架。所以ServerSuperIO在采集本范围内的数据信息与控制外，还要形成与上一级的ServerSuperIO进行数据交互，以及接收下一级的ServerSuperIO的交互数据，那么ServerSuperIO之间就形成了级联的关系，主要完成两大职责：数据的级联上传和反向控制，进而对设备本身进行级联控制。
结构示意图如下：
设备之间的通讯、控制
采集与控制单个设备，在实际应用中还远远不够，还要能够设备与设备之间进行信息传递与控制，并且返回给发送控制源设备确认信息。例如：在监测流量计严重报警的情况下，是否应该调节或控制液体源头的阀门。类似的例子很多。
在ServerSuperIO最新的3.1版本中（还没有发布），支持设备向另一个设备发起传递信息和控制后，被控制设备是否立即返回确认信息，还是自主异步决定返回确认信息。增加了异步返回确认信息的功能，因为控制命令只是发给了另一个设备驱动，设备驱动还会进一步与实际的硬件设备进行交互，与实现硬件交互成功后，再返回确认信息给发起的源设备驱动。
示意图如下：
与云端的交互、控制
ServerSuperIO提供了服务驱动的接口，一些除设备驱动类的功能以外，都可以以服务驱动的方式存在，例如：多设备采集的数据的融合模型计算、与其他平台或上层进行交互等等，在此仅以与服务端进行交互为实例进行介绍。与设备驱动之间的交互与控制不同的是，设备驱动主动把采集的数据信息传递给服务驱动，服务驱动与云端进行交互，在接收云端指令后，发起传递信息或控制设备驱动，设备驱动再返回确认信息给服务驱动。
示意图如下：
控制模式
（1）轮询模式：当串口和网络通讯时都可以使用这种控制模式。当有多个设备连接到通讯平台时，通讯平台会轮询调度设备进行通讯任务。某一时刻只能有一个设备发送请求命令、等待接收返回数据，这个设备完成发送、接收（如果遇到超时情况，则自动返回）后，下一个设备才进行通讯任务，依次轮询设备。如下图：
（2）并发模式：只有网络通讯时可以使用这种控制模式。并发通讯模式是集中发送所有设备的请求指令，框架是采用循环同步方式发送请求命令。还有进一步提高的机会，采用并行异步方式集中发送请求命令。硬件设备接收到指令后进行校验，校验成功后返回对应指令的数据，通讯平台异步监听到数据信息后，进行接收操作，然后再进行数据的分发、处理等。如下图：
（3）自控模式：只有网络通讯时可以使用这种控制模式。自控通讯模式与并发通讯模式类似，区别在于发送指令操作交给设备驱动本身进行控制，或者说交给二次开发者，二次开发者可以通过时钟定时用事件驱动的方式发送指令数据。硬件设备接收到指令后进行校验，校验成功后返回对应指令的数据，通讯平台异步监听到数据信息后，进行接收操作，然后再进行数据的分发、处理等。
自控通讯模式可以为二次开发者提供精确的定时请求实时数据机制，使通讯机制更灵活、自主，如果多个设备驱动使用同一个IO通道的话，时间控制会有偏差。如下图：
（4）单例模式：只有网络通讯时可以使用这种控制模式。在一个服务实例内只能有一个设备驱动，相当于一个设备驱动对应着N多个硬件设备终端。更适合通讯的数据协议有固定的标准，以命令关键字处理不同的数据。适用于高并发的硬件终端设备主动上传数据，服务器端根据数据信息进行处理和返回相应的数据。如下图：
跨平台
（1）Windows运行效果
（2）Linux运行效果
到此，相信大家对“ServerSuperIO的相关知识点有哪些”有了更深的了解，不妨来实际操作一番吧！这里是亿速云网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
