正文
支持一个设备驱动，同时支持串口和网络两种通讯方式，可以监视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通道的话，时间控制会有偏差。
同样涉及到数据的分发，和并发模式一样。
