主题：【原创】自动控制的故事（一）（完） -- 晨枫

计算机对自动控制的影响要是只局限在离散控制理论上，那也就不是计算机控制了。事实上，80年代以后新建的化工厂，基本都采用计算机控制。说是可以采用比PID更先进的技术，实际上，绝大多数还是在用PID，加上顺序控制，按部就班地执行一系列动作。那计算机控制的好处到底在什么地方呢？

过程控制的实际装置最初全是直接安装在现场的，后来出现气动单元仪表，可以把压缩空气的信号管线从现场拉到中心控制室，操作工可以在中控观察、控制全厂了。电动单元仪表防爆问题解决后，中控的使用更加广泛。操作工坐在仪表板前，对所辖工段的情况一目了然。但是随着工厂的增大和过程的复杂，仪表板越来越长，一个大型化工厂随随便便就可以有上千个基本控制回路和上万个各种监控、报警点，仪表板非有几百米长不可，这显然是不可能的。生产过程的高度整合，使一两个人控制整个工厂不光满足削减人工的需要，也对减少通讯环节、综合掌控全局有利。所以，计算机显示屏就不光是酷，而是必须的了。另外，计算机控制使现场仪表（阀门、测量变送器等）的自检成为可能，大大提高了系统的可靠性。于是，计算机控制就是不花没人性了。

计算机控制从一开始的集中控制（用IBM的大型机）到现在的分散控制（所谓Distributed Control System，DCS）走过一个螺旋形上升的过程。集中控制的要害在于风险集中，要是大型机挂了，全厂都要失控。分散控制将全厂划分为若干条条块块，用以微处理器为基础的一个控制用局部网来分散控制，主要子系统都是实时冗余的，故障时在第一时间内切换到备用系统，主系统和备用系统在平时定期互相自检、切换，以保证可靠。分散控制显然大大提高由于计算机本身引起的可靠性。但是现场仪表和接线终端（field terminal assembly，FTA）不是冗余的，整个可靠性链还是有漏洞。另外，控制局部网的同轴电缆长度有物理限制，FTA到DCS的长度也有物理限制，所以最后分散控制还是不怎么分散，全是集中在中控室附近或地下室里。不过DCS在地理上的集中，并不妨碍其在逻辑上的分散，只要不是一把火把 DCS的机房烧掉，部件可靠性的问题还是可以很好地隔离在小范围。

既然DCS是一个局部网，那就有一个通信协议的问题。DCS基本上用两大类型的通信协议：轮询（polling，中文的准确译名是什么？）和中断。轮询由中心控制单元轮流查询所有子系统，不管有没有数据更新，到时候就来问一遍，所以不管什么时候，系统地通信流量都很高，但是恒定。中断方式正好相反，子系统自己先检查一下，如果数据没有变化，就不上网更新；直到数据有变化，再上网“打一个招呼”。这个方式的平时通信流量较低，所以网路带宽要求较低。但是生产过程发生异常时，大量警报数据蜂拥而来，如果带宽不够，就会发生通信阻塞的问题。所以，中断和轮询到最后对带宽的要求是一样的，因为谁也不能承担生产过程异常时通信阻塞的后果。

二十年前，Honeywell是第一个吃DCS这个螃蟹的公司，今天Honeywell仍然是行业里的老大，尽管其设备昂贵，被戏称为Moneywell。当年的DCS全是量身度造的硬件、软件。今天在“开放系统”（open architecture）的大潮里，DCS的制造厂家都纷纷将控制台和计算、网络控制单元转向通用的WINTEL或UNIX平台，自己专注于工控专用装置（如基本控制装置，包括I/O）和系统的软件整合。但是这带来了新的问题。通用/商用硬件、软件的可靠性常常不能满足24小时、365天的连续运转要求。对于大多数IT来说，机子坏了，两小时内换上就是很快的了。但是对于生产过程来说，这是不可容忍的。开放结构容许将DCS和经营、管理、办公网络相连接，极大地提高了信息交流速度和深度、广度，但也带来了网络安全问题，紧接着就是DCS前面竖起一道又一道的防火墙，把数据分享和远程操控压缩到最低。另外就是WINTEL夜以继日的不断更新换代，是硬件、软件的稳定性十分糟糕，没有过多少时间，又要升级，又是头疼。这是DCS的第二个螺旋形上升，只是现在还是盘旋多于上升。

计算机控制的领地也在扩大，类似USB那样的技术也开始用于数字化的仪表。过去的仪表都必须把信号线拉到接线板（marshalling panel）上，然后再连到FTA上，这样同样远在百把米外的10台仪表，需要并行拉线，很浪费。用了类似USB的现场总线（field bus），各个仪表可以“挂”在总线上，然后一根总线连到DCS就可以了，大大节约拉线费用和时间，对系统（如加一个测量用的变送器或控制阀）的扩展也极为方便。

DCS的最大优越性是可编程。这不是简单的像PLC（programmable logic controller，可编程序逻辑控制器，多用于机电控制）的梯形逻辑那样编程，而是可以像C、FORTRAN那样“正规”的编程。没有在IT干过，只能和学校里计算机语言课程和大作业的程序相比。DCS编程和平常的编程相比，还是有一些特点的。首先，DCS的程序属于“再入”式，也就是定时反复运行的，而不是一次从头到底运行就完事的。所以DCS程序可以在运行完毕时在内存里存放数据，到下次运行时再调用，形成所谓“递归”运算。这既是优点，也是缺点，要是别人在你两次运算中间把那个中间数据更改了，你就惨了，找债主都不容易。

DCS程序的特色是实时，所以其执行非常取决于一系列事件在时间上的顺序。时序上要是搞岔了，老母鸡也就变鸭了。问题是，分散控制要求越分散越好，不光是可靠性，在系统资源的调度上，分散了也容易使系统的计算负荷均匀。这样一来，一个应用程序包常常将一个巨大的程序打散成很多小程序，各自的时序和衔接就要非常小心。

和学术型控制计算程序最大的不同，或许还在于对异常情况的处理。一个多变量控制问题在实际上常常会有部分变量处于手动控制，而其余变量处于自动控制的情况。这在理论上是一个麻烦，在实际上是一个噩梦。不光要考虑所有的排列、组合，还要考虑所有情况平顺的切入、切出，不同模式之间的切换。还有就是要考虑异常情况下如何安全、自动地退出自动控制，交还手动控制。有时操作规程上的一句话，程序写写就是一页。如果操作规程上来一句“视情处理”，那就更惨了。在所有控制程序中，控制计算通常不超过30%，20%为人机接口功能，而50%为异常情况处理。

计算机控制不是因为更先进、更有效的人机界面才开始的。从一开始，人机界面就面临一个管中窥豹的问题。计算机的CRT显屏只有这么大，不可能 “一言以蔽之”，在一瞥之中把所有的过程信息尽收眼底。计算机可以不断地换屏，分段显示其他装置、工段的信息，但是把所有的工段、装置分别用各自的画幅表示，如果没有有效的组织，找都不容易找到，就像在同一个目录里杂乱无章地放上百把个文件一样。分级的菜单是传统的解决办法，但是要逐级上去再逐级下来，很费时间，情急之中，往往来不及更换。大键盘上short cut键可以“一键调出”，但需要死记硬背，这可不是几个、十几个画幅，而是上百个甚至更多。很长时间以来，如何有效地在画幅之间导航，可以在最短时间和最少点击内，不需要死记硬背，就可以直观地找到所需要的画幅，一直是一个令人头疼的问题。

人机界面设计的另一个问题是色彩。还记得DOS 2.0时代的WordStar吗？那是黑底绿字的。那时候，CRT亮度不足，寿命也糟糕，黑底可以延长寿命，绿字可以增加反差，帮助阅读，反正机房是暗暗的，黑底并不伤眼睛。到了WordPerfect 5.0的时候，就是蓝底白字了，字和背景之间的反差大大减小，蓝底也比较适宜于在明亮的房间内使用。到了Word的时代，没有昏暗的机房了，基本上都用像纸上写字一样的白底黑字了，再用黑底绿字，太伤眼睛。

中控室计算机显示也经历了类似的旅程。早期DCS的显示都是黑底绿字的，到了用WINTEL或UNIX的时代，很多人出于习惯，仍然采用黑底绿字，但是现代人机工程研究表明，浅色背景大大减低眼睛的疲劳，在明亮室内的灯光对屏幕的反光也小，所以控制室的显示开始向浅灰背景进化了。人机工程研究同时发现，色彩可以作为过程信息的一部分，天下太平的时候，应该用最不显眼的灰色，所有的图形、数据都用不同深浅的灰色来表示，只有在过程参数越限或报警时，才采用彩色显示，这样可以一下子就把操作工的注意力吸引到需要的地方。但是，出于习惯思维，很多地方还是大量采用各种色彩表示不同的设备状态和参数，即使是正常状态也是一样。这样在平日里色彩缤纷很好看，但在异常情况时，不容易在万马军中找到上将的首级，实际上是舍本逐末。

显示器的布置也很有讲究，少了当然不行，也不是越多越好，一个操作工的视界的上下左右有一定的范围，控制台的色彩、构造、照明都不能想当然的。这不是助长修正主义，而是保持操作工最有效地控制生产过程的要求。

传统上，如果操作工不抱怨，控制回路的性能就是可以接受的，除非你想精益求精，一般不会去没事找事，重新整定参数。在对经济效益斤斤计较的今天，生产过程的工艺条件被推到极端，对控制性能提出极大的挑战，控制回路必需时时、处处都在最优状态。随着控制回路数的迅速增长，单靠人工观察，已经难于随时掌握所有控制回路的性能状况了。控制回路性能评估技术应运而生。

理论上，对一个过程可以设计一个最优控制，其中一种就叫最小方差控制。这其实是线性二次型最优控制的一种，控制作用比较猛，但是这是理论上的极限，控制方差不可能再小了。90年代时，理论界提出一个方法，可以用闭环辨识的方法，不辨识模型，而是直接确定理论上的最小方差，然后将实际方差和理论上的最小方差相比，判别控制回路是否需要重新整定。这个方法开创了控制回路性能评估的先河，但是在实用上不容易排除不利影响，应用不多。

然而，不和理论上的最优值比较，而是和实际上的理想值比较，就可以绕过很多麻烦的理论问题。比如说，流量回路应该在1分钟内安定下来，那理想值就是1分钟。通过快速富利叶变换和频域分析，可以将理论性能和实际性能相比较，迅速确定回路的当前性能状况。最要紧的是，这可以用计算机自动采集数据，自动计算，每天早上（或随便什么时候）给出报表，控制工程师可以一目了然，哪些回路需要重新整定，哪些没有问题，可以有的放矢。实时频域分析还可以将所有以相近频率振荡的回路罗列出来，接下来控制工程师就可以按图索骥，找出害群之马了。

控制回路性能评估的下一步当然就是自动整定。这实际上是一个简化的、断续运行的自校正PID控制器，在理论上已经没有问题，但实用上还有很多可靠性问题没有完全解决，现在产品不少，但实用的还是不多。

对控制回路性能评估的更进一步，当然就是对生产过程的故障诊断了。故障就是异常情况，异常就是和正常不一样。所以故障诊断的核心在于如何探测这“不一样”。

故障总是有蛛丝马迹的，问题在于工业过程的数据量太大，在大海里捞针，等捞到的时候，常常已经时过境迁了。在数据分析中，PLS（其实是Peojection to Latent Structure，而不是一般所认为的Partial Least Square）和主元分析（Principal Component Analysis，PCA）是很流行的方法。PLS和PCA将众多相关的变量归拢到少数几个“合成”的变量，这样一个有大量变量的复杂大系统就可以简化为一个小系统，就从大海捞针变为碗里捞针了。捞出来的针不再是单个的变量，而是变量的组合。这和实际是相符的，故障的早期征兆常常是若干变量的组合，而不能单从一两个变量上看出来。

PLS和PCA还可以和图形方法结合起来使用。比如说，将那些合成变量标称化，就是除以正常值，那所有合成变量的标称值就是1。把所有变量画成“蜘蛛图”（spider chart），每一个蜘蛛脚代表一个合成变量，由于合成变量的标称值都是1，蜘蛛图就是大体为圆的。如果哪一个脚出现变化，蜘蛛就不圆了，非常容易看出异常来，接下来就可以有的放矢地寻找故障的早期迹象了。

图形数据分析的另一个路子是所谓co-linear分析。这是IBM早年琢磨出来的一个东西，理论上简直没有东西，但要求换一个思路，正所谓退一步海阔天空。平常的数据点，三维以上就没法画了。但是如果把三维空间的所有数轴画成平行线，而不是常见的直角坐标，那三维空间里的一个点，就是连接三根平行线的一根折线。如果仅此而已，那也就是一个简单但愚蠢的数学游戏。平行坐标系的妙处在于，平行线可以尽着画，所以5维、20维、3千维，只要纸足够大，都可以画，而且可以看见，而不是只能想像。平行坐标只有一个缺点，就是只能表述离散的点，而难以表述连续的线或面，但这对计算机采集的数据来说，不是问题，计算机采集的数据本来就是离散的点。这样，用平行坐标把大量的数据点画成折线簇，可以很直观地看出数据中的模式来，

故障诊断的另一个思路是对整个过程进行辨识。辨识出来的模型表述系统的行为，故障当然就是行为的改变，所以将实时辨识出来的模型和正常模型相比较，就可以判断系统是否出现异常或故障。

计算机和模型的另一个用处就是仿真。仿真（simulation）也叫模拟，但是模拟容易和模拟电路（analog circuit）搞混，所以现在叫仿真多了。只要对实际过程有一个足够精确的模型，计算机是可以相当精确地模仿实际系统的行为的。

仿真有静态仿真和动态仿真。静态仿真基本上就是解一个巨大的非线性联立方程组，描述空间分布的微分方程也被有限元方法分解了。现代静态仿真已经可以做得相当精确，但这也是在多年结合实际过程数据“磨合”模型的基础上才能做到的。静态仿真大量用于工艺设备设计计算，但是对研究实际过程的真实行为的作用有限，因为对整个生产过程和工艺的仿真要考虑进各个设备动作的时间和控制回路的影响，这些静态仿真是无法体现的。动态仿真要解同样巨大的联立微分方程组，由于要达到实时或更快，一般只能大大简化，否则计算速度跟不上。希望有朝一日，动态仿真可以达到静态仿真同等的精度，而不必担心损失计算速度。

仿真在工业上十分有用。现代化工厂越来越稳定，越来越安全，很多操作工一辈子也没有遇到过真正危险的情况。但没有遇到过不等于不会遇到，操作工必须接受足够的训练，只有这样，才能当遇到危险情况时，首先能及时、正确地识别故障，然后才能及时、正确地作出反应。这就要靠仿真训练了。现代化工厂也在不断地拓展工艺参数的极限，经常需要做各种各样的试验。有了仿真，就可以预先验证试验的构思，和验证对紧急情况的处理。

仿真更是控制工程师的好帮手，新的控制回路先放到仿真上试一下，得出初始整定参数，验证异常情况的处理能力，然后再放到真家伙上，可以避免很多不必要的惊讶。

仿真的一个远亲是实时最优化（real time optimization，RTO）。对于斤斤计较的现代制造业，实时最优化当然是求之不得的。实时最优化就是把整个生产过程当一个大的实时仿真来运算，实时（实际上是每小时）计算出最优工况。想法是好的，困难是多的。首先，那么大一个方程组收敛不容易，要划成很多条条块块，分别求解，然后拼起来。问题就出在“拼”上，边界条件碰不拢怎么办？模型总是有相当的简化，其中有些参数必须和实际测量值符合，有些就没有实际测量值对应，就是“经验系数”（fudge factor）了。这些经验系数就是承担收拾烂账的，边界碰不拢，就调整经验系数，使他们对齐。问题是，好多时候，这一招也不灵，所以实时最优化的喇叭吹得很响，真正用起来的很少，花了大钱最后放弃的也不在少数。