GE数字集团 | 余思源
不久前收到客户消息，他们现场部署的一套冗余的CIMPLICITY服务器响应很慢，工程启动需要4个小时，在业务高峰期，来自PLC的信号甚至要30分钟才能反应在监控画面中。
30分钟高铁可以从上海开到苏州了，4个小时可以到北京了。（客户表态说他们情绪很稳定，但很想问GE老板的电话是多少……）
提供良好的支持和客户体验是GE Digital成为“客户之选”的重要原因。
针对客户反馈的具体问题，我们致力于为客户排忧解难，提供符合客户期待的解决方案。
1
Current Situation
现状
系统大致情况是，现场50台PLC，通过一套IGS采集，两台CIMPLICITY Server组成冗余架构，每台Server运行一个CIMPLICITY工程，工程中配置了一个OPC UA的Port（端口），一个Device（设备）绑定该端口，约1万个数组型Device Point（设备点），然后从这一万个Device Point又派生出来约30万个Calculation Point（计算点），最终画面上显示的信息来自于这30万计算点的组合。
简化的各模块之间的对应关系如下图所示。
注：图中蓝色区域为CIMPLICITY内部模块，绿色为其它模块，下同。
2
Reasons
原因
联系GE的技术支持团队后，我们判断正是由于这30万计算点导致了系统性能较差。
工程中设备点的平均采样时间是2秒，每次设备点值发生变化时，都会导致其派生的计算点重新运算一次。但由于该工程计算点数量太多，而且工程中负责计算点更新是单一进程（PTMDP），导致了上一轮计算点的更新还未结束，设备点又有新的变化，于是又触发新一轮的更新。在业务繁忙时，此场景反复出现，系统进程发生溢出，大量计算点无法更新，最终客户观察到界面上显示的信息也停滞不变。
如下图所示，ptmdp.exe进程已经占用了1.4GB左右的内存。
3
Solutions
解决方案
原因找到了，接下来要和客户讨论解决方案了。
方案一
既然一台服务器带不动30万计算点，那么把原工程分拆成三个工程，然后运行在三台服务器上不就解决了。考虑到冗余架构，我们建议客户再买四台服务器和四套CIMPLICITY Server的授权。
客户回答很爽快，要考虑成本和预算。
方案二
既然不能增加软硬件成本，那我们就在现有的服务器上改造。
考虑到原服务器配置了64GB内存，高峰时期的内存利用率小于20%，而且多个CIMPLICITY工程也可以运行在单台服务器上，我们建议客户依然把原工程分拆到三个工程，同时运行在原服务器上，然后更新一下界面中引用点的工程名。
客户考虑了片刻后表示，画面太多，改动工作量太大，可否再换个思路？
方案三
如何在既不增加成本，又不投入更多资源的基础上寻找最优解呢？
继续深挖系统，我们发现一个有趣的现象，从PLC到CIMPLICITY系统的数据流经过了一个分-合-分的过程，看下图。
这是一套典型的离散行业SCADA系统，大量的信息为布尔（Boolean）类型，例如一台设备处于运行，故障，启动等不同状态。在IGS系统中，我们将其定义为一个16位的布尔数组标签，同样，在CIMPLICITY中也定义了一个16位的布尔数组点（设备点）与之对应，最后通过运算表达式再拆成16个单独的布尔型计算点。
这个方案第一眼看上去就很奇怪，既然数据的源头和使用者都是按位（Bit）来用，那中间的两个数组不就多此一举，而且不可能每个数组的16个Bit都被占用，一定有多余的信息被采集了。
按照这个思路，我们把采用数据流变成以下这个方式。
PLC中有16个布尔变量，同样在IGS中定义16个布尔标签，在CIMPLICITY中定义16个布尔设备点，三套系统的信息一一对应，相互关系简单而清晰。
可能有人发现了，这种方案下CIMPLICITY确实减少了一个设备点，但是在IGS中新增了15个标签，系统岂不是更复杂？
真实的情况则更简单，新版本的IGS和CIMPLICITY配合使用，可以支持设备点直通模式。我们在IGS中仅需要定义多个通道（Channel）和设备（Device），而无需定义标签，而在CIMPLICITY的设备点配置中，地址一栏写入IGS的通道，设备，以及PLC中的地址即可。
以这个地址为例，ns=2;s=NCY_EA281.EA281.DB12,X1.1，其中NCY_EA281是IGS通道名称，EA281是设备名称，DB12,X1.1则是对应PLC中的内存地址。
所以，在这种方式下，IGS和CIMPLICITY两套系统的配置工作量都有所降低。
新的数据流如下：
架构更新后，各模块之间的对应关系如下图所示。
与现场PLC对应，在CIMPLICITY新工程中配置了50个OPC UA的端口，50个设备各自绑定一个端口，将原来的30万计算点全部改为设备点，并分配到对应的台设备中。由于这30万点的名称不变，所以画面的配置不需更改。
可能有人会问，将30万计算点改为设备点，那负责设备点通讯的进程压力岂不是很大，是否能承受呢？
答案是可以的，由于我们在CIMPLICITY工程中配置了多个端口和设备，然后将30万设备点分配到不同的设备中，平均下来每台设备仅负责约6000个点的通讯，而系统会为每个端口（这里即每个设备）单独启动一个进程，所以每个进程消耗的资源很少，如下图所示。
同时，由于计算点数量的大幅降低，对应的ptmdp.exe进程压力也小了很多。
4
Conclusion
结论
为了清晰的对比系统改造前后的效果，我们做了一张表格。
可以看出，系统改造后对性能的提升还是很明显的，满足客户预期。
今后，如果再遇到这种既要高性能，又要低成本，还要方便运维的SCADA项目，大家知道该如何选择了。
最后，客户表示现在没问题了，但二期还要再增加30万点（我想……要不还是把老板电话给他吧。）
