工控机上位机软件的开发历程

上位机软件的主要功能是采集各仪器的数据，然后存储起来，并传送到环保局平台。

刚开始使用的是组态软件（用以显示流程图），然后再开发了报表软件、数据上传软件。因为组态软件使用的是标准Modbus协议，而很多仪器使用的协议根本就是自定义的，所以还要加一个协议转换软件，把各种各样的协议转换成Modbus协议，让组态软件去读。除此之外，我们还希望软件能够开机启动，就增加了延迟启动的第三方软件。

这样一来，每个站点要安装和部署的软件非常多和杂乱。加上每个站点都有自己的特点，软件出现了大量的版本。有上位机的版本管理、升级维护时，出现了极大的麻烦，管理成本极高。很多时候会有这样一种情况，前面开发的人走了，后面就没有人能维护他的软件了。

基于上面的情况，我和团队重新设计和开发了上位机软件，具有以下特点：

（1）软件集组态、采集、传输、报表、自动启动等功能于一体，一台工控机只有一个上位机软件。

（2）上位机只有一个版本，所有站点都一样。站点的不同特点通过配置文件来实现，而这个配置文件不随更新而变化。

（3）仪器五花八门，但我们把它们归于一体，用同一个模型去表现。

（4）在对仪器的支持和界面功能上，具有强大的扩展特性和灵活性。

以下是部分软件界面截图：

仪器归一化设计

这是具体内容的第一篇，我们先来讲述仪器的归一化设计。

仪器是各种功能都有的，我只举我们在环境监测这方面所用到的仪器。我们要测试水是不是有污染物质，污染到什么程度，我们要测试水体的高锰酸盐指数、氨氮、总磷、总氮等值。我们的站房有一个后备电源，我们要知道市电是否断电了，是否在用备用电源。我们的站房是有空调的，我希望知道站房的温度和湿度，于是就有了一个温湿度计。我们可能还会有流量计、DTU、数字仪等仪器。这些仪器跟工控机的连接也不尽相同，有的使用串行线，有的使用网线。用网线的仪器，有的作为客户端，有的作为服务端，有的使用UDP。总之，这些仪器的通讯协议是五花八门的，通信链路也是有区别的。

但我们需要对仪器做出归一化设计。

其实无论仪器有什么功能，工控机对仪器的操作无非就两个：读和写。读的话，可能是读到测量的值、仪器的状态等；写的话，就是启动仪器测量、修改仪器的参数等。而读和写的操作，都是通过发送和接收完成的。虽然通信协议各不相同，但我们总是可以把发送和接收的内容转化为最基础的字节流。要发送怎样的字节流，接收到的字节流如何解释，就要根据仪器的特性去定义了。

根据这样的特点，我们为所有仪器定义了一个基类，它包含了发送字节流和接收字节流两个方法。而所有仪器类，都继承自这个基类。

每个仪器特定的类，只需要完成拼装发送的字节流，和解析接收的字节流即可，它不需要理会如何发送和接收。而实际上的发送和接收，我们知道链路是有多种的，如上面提到的串行线和网线。使用哪种方式去传输，我们需要根据仪器的属性去判断。如下图所示的方法，在基类里实现。

解决了上面仪器类的结构设计以后，我们需要考虑仪器的属性如何表示和存储。我们把所有仪器都称为设备，设备包含以下内容：

（1）名称。

（2）传输方式，以及传输的参数。例如用串口，那应该有串口号、波特率等。如果用网线，应该有IP、端口等。

（3）使用的通信协议。选定之后，上位机能够找到相应的通信协议类，对字节流进行操作。顺便一说，我们把通信协议类用反射的方法去做，每个协议是一个dll，选择不同的协议即会执行不同的代码。

（4）因子列表。

没错，说到这里，我们就发现，工控机设备里有一个因子的概念。因子是什么？这个比较难解释。从最原始的因子来看，因子就是仪器的测量值。例如我们有一台温湿度计，它的测量值会有两个，分别是温度和湿度。我们就把温度和湿度作为两个因子。我们对因子的概念进行扩展，把状态也作为因子。例如仪器的工作状态、故障状态，都可以看作是一个个的因子。甚至，我们把控制仪器的命令，也看成是因子。例如是启动测量、更换运行模式，每一个动作都看成是一个因子。这样下来之后，仪器的所有功能，都变成了因子的列表。因子有很多属性，但不是所有因子都一样的。名称是我们想到的唯一一个共性属性。我们在实际的开发过程中，定义了几种因子：

（1）实际因子：就是测量值。它应该有单位、超标限制、因子地址（Modbus协议）等属性。

（2）计算因子：跟实际因子类似，只是它不是直接读取仪器值得到的，而是根据实际因子计算出来的。这样的话，计算因子就要有一个表达式的属性，例如是：温度*9/5+32

（3）状态因子：仪器的状态。它的值不一定是数，可能是一个字符串。

（4）反控因子：对仪器的控制命令。可以用一个数字去表示控制的类型，工控机只需要在协议类里面解释清楚即可。

通过上面的方法，我们把所有仪器都归一成统一的类了。