框架总体的设计

2.1 宿主程序设计

作为插件式应用框架，要有一个宿主程序来承载、加载插件，为插件、驱动提供可运行的环境，使宿主程序与插件无缝对接。宿主程序与插件的关系是水和鱼的关系，有水没鱼，水就失去了价值；有鱼没水，鱼就会死去。从关系的角度来分析，开发框架的目的是什么？是与其他事物发生关系，包括：开发者、二次开发者、应用者、插件、甚至其他软件或组件等。发生的关系越多、相处越融洽，证明这个框架的价值越高。所以说，一个好的框架平台，不仅体现了开发者的技术，同时反应了开发者的情商。

SuperIO框架使用NET反射技术开发插件管理机制，在本章中不详细介绍具体的技术细节，在《第8章插件引擎设计》中再进行详细的介绍技术应用。

那么一个框架的宿主程序应该怎么样去设计呢？或是说从哪些方面去考虑设计问题？在开发SuperIO框架的时候，一直在思考这个问题。首先，这个问题不应该从技术角度去考虑，而应该从人的角度去考虑如何做，应用者的角度、二次开发者的角度来规划宿主程序。

从应用角度来分析，宿主程序应该包括：用户管理、设备驱动管理、设备状态监视方式、自定义UI插件显示方式、自定义输出数据插件操作方式、服务插件的服务方式、软件运行的监视方式、串口IO通道监视方式、网络IO通道监视方式等等。这些是我们从大的方向规划的，还需要再进一步细化，指引我们的开发工作。

用户管理，要支持多用户以及用户权限分配。针对实时数据采集框架，面对现场应用的时候，肯定会涉及到两个角色：使用人员、工程师人员。针对使用人员的权限定位：可以查看参数和数据信息。针对工程师人员的权限定位：不仅拥有使用人员的权限，还可以修改参数。用户管理的菜单，如下图：

设备驱动管理，设备驱动（插件）是通过接口、抽象类设计的框架核心部分之一，可以把二次开发好的设备插件加载到框架中运行，完成数据采集、校验、解析、处理等相关操作，以及进行命令、数据的交互。同时，设备驱动管理还应该具体删除相关的设备插件的功能。增加设备插件，如下图：

设备状态监视方式，我们可以把它称为“设备运行器”，它并不是对不同类型设备驱动的所有参数、属性等数据进行简单显示，而是对设备通用参数、属性、实时状态等数据进行显示、监视，例如：设备ID、设备名称、地址、通讯类型、IO参数、IO状态、通讯状态、设备状态、报警状态、设备类型和编号等。如下图：

自定义UI插件显示方式，二次开发者在规范的接口基础上开发数据显示方式，挂载到框架的配置文件中，当用户单击某一个显示视图的时候，以Tab Form的形式显示，并且可以单击按钮进行关闭，如下图：

自定义输出数据插件操作方式，这种输出数据的是对实时数据的导出，更多的是以事务性的服务存在，可以把一类的设备数据输出成多种数据格式。输出数据插件可以通过配置文件进行加载，只要设备驱动有数据更新，就把数据通过接口传递给输出数据插件，进行输出操作。不在配置文件中配置插件信息，则程序不进行加载，不进行输出操作。所以，这种事务性的服务不需要界面来完成，可以在宿主程序启动时通过代码来完成。

服务插件的服务方式，这种服务是长期运行的事务性任务，所以更复杂一些。有些服务需要随宿主程序启动而自动运行，有些服务需要人工手动启动才运行。在宿主程序启动的时候要把服务的信息加载到菜单上，菜单里显示的这些服务可能有些已经启动了，有些需要通过单击操作，显示窗体并填写必要的信息后才可能启动。所以，宿主程序与服务插件不是单向交互，而是双向数据、事件交互。例如：把设备的数据采集上来、处理之后，要把数据上传到服务中心或其他区域，就可以开发一个插件来完成这项任务，如下图：

软件运行的监视方式，这是一种实时日志监视器，可以监视框架运行情况、以及设备的运行情况。把异常的信息可以友好的显示出来，把异常的详细信息保存到日志文件。我们可以把它称为“运行监测器”，对于实时数据采集框架的运行是很有帮助的。如下图：

串口IO通道监视方式，当某一个设备驱动以串口方式通讯时，当串口参数动态发生改变时会在串口监视器反映当前串口IO状态，例如：增加串口、删除串口、串口号和波特率的改变等。如下图：

网络IO通道监视方式，相对好设计一些，只需要对Socket实例的连接和断开进行事件反映，Socket实例有效时把信息增加到网络监视器中，Socket实例无效时，并释放了相关资源后，从网络监视器删除相关信息。如下图：

基于以上的分析，我们需要构建一个完整的宿主程序，必要的功能要有，但是这个程序不一定很复杂，因为有些功能、响应、属性、数据等可以放到设备插件中完成，在《第3章设备驱动的设计》中详细介绍设计情况。构建的宿主程序，如下图：

如果光有了宿主程序，那么还没有分析全面。还需要以二次开发者的角度分析宿主程序是否能够与二次开发者保持良好的关系。这里涉及到宿主程序存在的形式问题，宿主程序作为SuperIO框架的一部分，是一个整体的组件。希望二次开发者继承宿主程序就可以快速构建一个自己的主程序，可以在此基础上扩展功能，这样的话，需要把宿主程序的关键控件的访问权限设置成protected。另外，宿主程序还需要一个配置文件，把二次开发者关心的参数可设置，例如：标题、版本号、公司名称等。

经过上述的过程，我们就对宿主程序有一个清晰认识和规划。界面的骨架已经搭建出来，在后期的开发过程序中从细节着手，逐步实现这些功能。但是，这样一个简单的界面需要很多类、模块等支撑。以后章节会对每个模块进行详细设计说明。

2.2 通讯机制设计

对于实时数据采集框架，通讯部分始终是软件的核心，要求高实时性、高稳定性。软件框架决定了软件运行的稳定性，以及以后的扩展性，所以需要对通讯机制、控制方式进行良好的设计。

在《1.通讯框架介绍》中的已经对应用场景进行了介绍，所以决定了软件框架在通讯方面的应用有两种方式：主动请求和被动接收。

主动请求方式又可以称之为呼叫应答方式或主从方式。也就是说，主动权在软件框架端，只有软件框架主动发送请求命令，从机（硬件设备、传感器等）接收到命令后并且检验数据的完整性，以及确定是否发给自己的命令，校验成功后，返回指定的数据信息，完成一次完整的链路通讯过程。呼叫应答通讯方式，如下图：

被动接收方式是软件框架实时监测IO通道，只要有数据信息就会提取出来，进行数据校验，检验成功后，分析、处理、保存数据信息。例如设备、传感器等定时发送状态数据。这种通讯方式，如下图：

在复杂的应用场景中，这两种通讯方式都有可能存在，此类情况一般是采用以太网链路进行通讯。针对只有外接串口的设备可以通过以太网转换模块来接入。

2.1.1 串口通讯机制

由于串口通讯的特性限制，避免多个硬件设备连接到串口总线出现数据混乱

现象，一般采用轮询模式的呼叫应答通讯机制。

2.1.1.1 轮询模式

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

2.2.2 网络通讯机制

轮询通讯机制是保证数据有序的发送、接收，避免并发数据在串口总线上出现混乱，但是这种通讯机制是以降低性能为代价的，适用于串口通讯，在以太网通讯中显然无法充分利用网络通讯的优势。以太网是独立信道、可以全双工通讯。为了充分发挥以太网的优势，在轮询通讯机制的基础上增加了并发通讯模式、自控通讯模式。一是为了提高通讯的性能，二是为了二次开发有更多自主控制权。