来源：荣峰正见（微信公众号）  作者：隋宝华

各个公司构建智能化控制系统（包括监控系统），所采用的软件架构，可谓五花八门，各显风骚。作者谈谈自己的认识，抛砖引玉，也给从事这个领域的同仁，提供一个可以引用的思路。

一.   操作系统

选择操作系统，作为思考的第一步。若您的设计还是基于传统的可编程控制器、PLC思想，那么就不是本文讨论的范围。

常见可选择的操作系统有：

   1.Windows

   2.Anddriod

   3.Linux

   4.Unix

 5.专有系统

Windows操作系统无疑是目前占有率最高的，也是首选。在互联网、物联网应用上，开发资源无比丰富，各种协议支持良好，安装、调试、服务成本相对较低，培养人才也是相对容易。

Anddriod系统，适合于独立封装的应用环境，弱化了互联网、物联网整体性、系统性的部署，大数据计算逻辑支持还有待提高，开发资源虽然丰富，但也存在很多不足。

Linux系统虽然也有不少用户，更多的应用还是因为JAVA的缘故。刻意开发一套基于Linux系统的非JAVA应用软件，肯定不是大对数技术架构师的选择，除非特殊需要。

Unix系统虽然功力强大，但由于其硬件体系价格昂贵因素，导致厂家基本放弃了运用此操作系统作为架构基础，除非特殊需要。Unix系统，目前聚焦在大型数据库服务上。

苹果公司的MAC系统、ios系统，属于专有系统，所有开发出来的应用，必须且只能在苹果公司设备上运行。这些专有的操作系统，只能作为整体方案的补充，而不能作为首选。

本文讨论的重点，放在Windows上。

二.   设计智能化控制系统需要考虑的现实因素

       1.     应用差异

每一个应用现场，都有些许差异，几乎找不到一模一样的应用现场。若试图尝试“一键安装，傻瓜式部署”，就真的走上了一条不归路！

       2.     控制逻辑差异

即使同时建设的两条生产线，生产设备一样，生产同一产品，控制逻辑可能都会存在无法避免的差异，这是因为设备属性的微小差异造成的。比如：同一批下线的汽车发动机，运转时，测试的声纹都是不同的，就是这个道理。由于差异的存在，控制逻辑一定会存在差异。

       3.     产线升级

产线不断的改造、升级，是常见的现象，正所谓“没有最好，只有更好”。随着生产设备技术的不断升级，产线的改造及升级变成常态化，只是改造升级的周期会有所不同而已。一旦产线改造升级，相应的控制逻辑、控制属性等，都将发生变化。

       4.     控制性能

不同的应用，有不同的控制性能要求。比如：电力领域，控制性能指标在200ms内完成，冶炼领域可能1s就够了。若需要200ms的性能，设计时没有必要技术保证，那么系统无法使用。强制使用，就是灾难！

       5.     物理隔离

控制系统的部署需要物理隔离。尽可能的切断互联网、企业办公网的对接。若必须对接，要有严密的安全方式。在此，忠告那些试图使用云计算能力的服务厂商，控制系统若没有物理隔离，未来所造成的损失，除了巨额的经济赔偿外，还将面临着繁琐而漫长的司法追责。

       6.     规避操控指令的级数效应

生产环境下的状态场是复杂的，根据不同的状态场，系统自动发出最适合的调节指令。状态场，可能有几十个、几百个参数构成，甚至更多。每一个参数的值又有一个上下线范围。根据不同刻度的上下线，多个状态场参数组合在一起，对应的操控指令条数是惊人的，很可能达到或者超过几千万条。试想一下，若您用机器学习的方法，创建了几千万条操控手法，如何使用？这实际上是由于简单思维，对业务理解不深刻造成的。

       7.     售后服务成本

若您交付的控制系统零故障，当然是好事！服务成本注定是最低的。客户现场出现的问题五花八门，难以一语说清，所以售后服务成本必须引起重视！

以上七点，是设计智能化系统之前必须要思考清楚的问题，这些问题不解决，等待的就是灾难。很多公司就是因为对上述问题的忽视而造成了毁灭性的结局。

三.   划分服务逻辑

兵法云“知彼知己，百战百胜”。有了上述共识，我们就开始设计软件架构吧。

首要工作是划分服务逻辑。即把有可能的独立单元逻辑，尽可能的拆分出来。然后，均实现成一个个独立的运算服务，注册到Windwow操作系统中。不怕多，就怕不够多。

以下，是实战的服务拆分思路：

1. 设备位号配置

2. 状态场获取

3. 数据清洗

4. 实时数据库

5. 感知计算

6. 预判计算

7. 斜率计算

8. 补偿计算

9. 积分计算

10. 寻优计算

11. 数据发布

12. 数据接收

13. 预警服务

14. 安全服务

15. 巡检服务

16. ......

当然，若您的系统只是监控，没有发送操控指令的要求（以上可以裁剪）。若是这样，这个系统也不是智能化控制系统，只是一个监控系统而已，不是本文讨论的核心内容。

四.   选择开发工具

理论上什么开发工具都可以。但是，作者更推荐采用c++、c#。打个比喻，可以上天，可以入地、下海。

系统代码实现时，离不开各种协议，c++、c#对各种协议的支持是近乎完美的。特别是针对OPC协议的支持，比其他任何工具性能都好。开发高可靠性智能化控制系统，就目前而言，没有第二个完美选择。

五.   柔性设计

若您开发的系统未来有更为广阔的应用前景，那么就务必思考柔性设计这个硬核的技术理念啦。

柔性设计，其目标就是在客户现场，实施工程师，无需修改软件系统，只是适配大量的数据参数，就可以完成智能化控制系统的实施。

柔性设计，不同的架构师有不同的理解。任何一本教科书都无法准确的归纳概括出来。有人说平台化就是柔性，也有人认为只要很轻松的满足了客户的需求，就是柔性设计。

柔性设计，就是控制系统与相配合数据配置文件的有机结合，很好的解决了客户的实际问题，同时又可以在其他客户复制，这就是柔性设计的核心，做到了，就是一款称赞的产品！

普通的配置文件相对容易，往往是静态的。最难理解的就是针对工艺流程、工艺参数相关的数据配置，不仅包含一些静态的数据参数，更大量包含很多基于工艺流程的动态参数信息。突破了这个，系统就是优秀的！

六.   安全性设计

生产安全永远都是第一位的，再好的系统，若做不到能够确保生产安全，也是毫无用处。没有人敢用一个不能确保生产安全的控制系统。生产安全性，做好以下几点：

1. 系统控制的上下线边界描述清晰，超出边界，无效。

2. 巡检服务。系统有个独立的服务专门做巡检。及时向预警服务发出可能的警告状态。

3. 预警服务，出现异常，立即发出预警信息。

4. 自动状态与手动状态的切换延时，不能超过1s。而且方便执行。

5. 禁止对接互联网、办公网。若需要生产数据发布到互联网、办公网，需要使用单向数据传输机制，生产网络向互联网、办公网传输数据。

   

七.   工具箱

任何一个精良的系统，都需要一整套的工具配合使用。我们简称工具箱。工具箱是面向现场实施工程的。给现场实施工程师提供丰富、简单的工具，会让项目实施进展加快。

工具箱的构建，是软件架构设计必须思考的。各种工具，务必要与运行的系统彻底分离，不要把各种工具绑定在运行的系统中。

工具与系统独自升级，互不影响。

工具箱的不断完善，又可以检验系统整体架构的合理性。

八.   云应用

把控制系统放在云上，这个思路坚决不能采纳，一旦通信线路中断，生产线将会出现致命的灾难！

大量鼓吹云控制的一切宣传，都是不负责任的行为，算力再强大，也是中看不中用。

九.   其他

至于您的软件系统需要怎么分层，怎么部署，如何切割模块、子系统，不是本文讨论的内容。