谈谈自控的组织管理

晨枫

自动控制顾名思义就是不需要人干预的，但自控也确实是需要人来规划、实施、管理的。有人的地方就有江湖，有人的地方就有山寨。自控的管理关系到自控的成败，不可不察。

7 P+ F8 P; l) l5 P( r) [& i1 E小公司、单一工厂的问题不大，但公司一大，自控的人事组织就比较复杂了，既要兼顾“深入基层”，又要兼顾统一管理。这不光是自控，技术线上都有这个问题。但同一公司内不同工厂、地区之间自控的共性较大，使得集中还是分布的问题尤其纠结。

广义自控的大类有很多，过程自控是其中很重要的一类，涵盖化工（包括石化、化纤）、造纸、冶金等连续生产过程的自动化。过程自控可以大体分三个层次：回路级的仪表控制，单元级的集中控制，装置级的先进控制。

所有自控都是从回路级开始的。这包括单回路控制、串级、前馈、选择性、分程等。这是传统DCS（Distributed Control System）的范畴。这一般涉及一个具体的温度、流量、压力、液位，也可以扩大到储罐液位到出料流量的串级等。单元级的控制的范围要大一点，比如精馏塔顶的温度-压力-回流罐液位-出料流量的综合控制。装置级的先进控制范围更大，通常涉及最终产品质量控制、产量控制、全装置能量/物料平衡等牵动全局的变量。

分布式管理以厂为基点在厂内配备相对完整的自控人手，包括自控工程师和仪表工，从回路级到装置级都就地解决。集中式管理则把自控人手集中到总厂级，具体工厂里只保留最低限度的人手，仅够救火用。分布式管理的好处是自控人手与用户结合紧密，不仅用户反馈快，也具有较强的ownership（主人翁精神？），不断改进的主动性、积极性强，自控应用的在线率高；坏处是厂与厂之间人员重叠较大，不利于资源共享。集中式管理的好处是人员配备紧凑，有利于资源共享，但是“中央”与“地方”容易有隔阂，谁都觉得“这”是对方的责任，ownership不强，新建成的自控应用容易“毕业就失业”。
/ X! O, \5 b( a7 r( P
一般情况都是分布式和集中式的某种程度的结合，但是向分布式或者集中式的偏向还是存在的。在不同的专业之间，也常有不同的比重。比如说，仪表工通常保持分布式，各厂保持自己的仪表工队伍；但自控工程师就可能分为基本自控和先进自控两摊，前者为分布式，后者为集中式；自控IT则全部为集中式。
) K8 z( O5 t( ^% C
仪表工分通用仪表工和专用仪表工。通用仪表工负责一般变送器、控制阀等典型仪表的维修，专用仪表工负责分析仪器、PLC（Programmable Logic Controller）和DCS硬件，通常两拨人之间有轮换，大家都轮点“好玩”的东西做做，但由于分析仪器、PLC和DCS需要更多的专业训练和经验，有的地方也实际上是固定的人手，不轮换。通用仪表工一般是定点的，直属厂里。他们不仅和操作工紧密配合，必须“人头熟”，也需要对具体仪表在装置中的具体位置和特点特别熟悉，需要抢修的时候，每分钟都是宝贵的，不可能派一个本事比天大但具体仪表在哪里还要对着图纸找半天的人来抢修。分析仪器的共性大一点，但品种也更多，各厂经常都是“孤儿”仪器，都有点不一样。即使厂家和型号一样，分析的东西不一样，calibration（校验？）也不一样，GC（气相色谱）峰值和 分离需要经验，也是定点支援比较好。PLC的共性更大，但这里和通用仪表相似，难点不在对PLC的编程，而在于对过程和控制逻辑设计的熟悉，这只有长期驻厂才可能做到。但DCS硬件就不一样。DCS硬件的共性很大，而且硬件支援人员不涉及具体的控制应用，与厂里具体过程的交互比较间接，十分有利于集中式管理。
. H2 d% Y7 @: Q2 }5 }! w+ {7 O
控制IT是一个新生事物。这是过去DCS  admin职能的大大延伸。现代DCS本身已经高度IT化。从Windows NT时代开始，很多DCS开始放弃专用操作系统和软件环境，而改用开放系统，尤其是Windows NT及更新版本和UNIX为基础，以及随之而来的Ethernet网络架构，不仅便于与常用硬件软件通用，还有利于与控制系统之外的一般IT结构整合。另一方面，底层（I/O处理、PID回路等）还是采用更加适合实时控制的专用环境。这样的混合架构需要很强的IT功力。负责DCS系统优化和软件维护、升级的DCS Admin对于domain、protocol、firewall这些传统IT的东西也要具有很强的掌握。但是和DCS硬件一样，DCS软件并不是针对特定工厂环境的，具有很大的共性，这也是集中化管理的有利因素。
  d; Y9 S% _' ~2 \* X
另一方面，由于开放系统的缘故，DCS数据已经与ERP（Enterprise Resource Planning）、MES（Manufacturing Enabling System）一级的系统高度整合。产量、开工率等营运管理方面的数据自不待言，还有各种辅助系统，典型的有Process Historian（过程历史数据记录系统，用于记录所有传感器数据、控制动作、控制设定和其他连续变化的数据）、Alarm Hisorian（警报记录，用于记录所有过程及系统警报、操作工人工干预输入、系统状态变化、文字信息message等离散数据）、回路性能分析监测（自动监测回路响应品质、阀杆粘滞等）、回路调校（对PID回路自动整定或者辅助人工整定）、先进控制（多变量控制、复杂计算、实时最优化等）、质量控制（产品测试数据管理、产品规格数据管理、产品批次管理等）、AOA（Alarm Objective Analysis）数据库等。这些五花八门的系统常常在不同的平台上运行，但数据需要共享，整合要求很高。这些平台通常都是商用平台，理论上“可以适用于任何环境”，实际上“魔鬼就在细节之中”，需要专业IT作为用户方和“主人”参加整合，否则肯定会出现很多三不管的事情，最后弄了个稀里哗啦。另外，很多系统的用户界面属于专用系统，比如Process Historian和Alarm Historian一般用Excel作为使用界面，但专用的Add-in超出了一般IT的保障能力，这就是自控IT的领域了。另外，与DCS的数据交换通常是通过OPC（OLE for Process Control），自控IT的人不仅要保证OPC通畅，还要合理规划流量，避免高峰造成堵塞和数据丢失。广义的现代控制系统中，自控IT的作用越来越重要，他们是必不可少的粘合剂。但由于他们工作的“普遍性”（适合总厂范围内的所有工厂）和特殊性（只有总厂级才有这样的系统，在各厂之间共用），他们很适合于集中使用，分布使用既浪费，也没有必要。

但自控工程师就比较纠结了，这也是集中化还是分布化的焦点。
3 f  q* Z. W  J, s
: r3 d& W  `& D. [- {. v5 v# q& N自控工程师需要集工艺过程、控制理论和软件设计的知识于一身，不仅需要熟悉各种自控工具，还需要熟悉工艺过程，应该具有在工艺过程和操作规程上顶半个工艺工程师的本事，至少要熟悉工艺工程师和操作工的语言，要“说得上话”。在工作上需要与操作工和工艺工程师紧密配合，以建立必要的人脉。所以最适合分布式管理，直接驻厂。但另一方面，先进控制技术在理论和工具上都越来越复杂，所有人具有所有技能也确实是一个浪费。
' ~/ z  s- P4 p5 o: s  F# g3 k
自控工程师的职责包括现有控制应用的维护和新控制应用的开发。新应用的范围很大，从简单的回路到到复杂回路，从图形界面到在线计算。这些功能与工厂的日常运作关系紧密，分布式管理最为合理。另外，操作工和工艺工程师对于自控里的专业分类并不熟悉，自控工程师常常是整个自控领域的“门脸”，有事首先找他们。如果是DCS硬件、软件的问题，或者自控IT的问题，再由他们呼叫有关人员援助。另外，隔行如隔山，工艺和操作工需要更改逻辑，常常会发现“语言不通”的问题，自控工程师对工艺熟悉，对自控也熟悉，就是天然的中介。事实上，越来越多的工艺改造并不需要大幅度的设备、管道、阀门的改动，而可以通过控制系统的精巧重组实现全新的功能。在航空上，先进飞行控制步进增加了安全性，还改善了油耗，甚至通过控制面共用降低结构重量。在化工等过程工业上，这也开始了。这里，自控工程师再次成为天然焦点，进一步强化自控工程师驻厂的好处。

+ |) t6 R5 G5 @' M4 \3 q. X另一方面，越来越多的先进控制应用（APC）开始出现，其主要特点在于多变量、约束最优、模型预估、非线性。这些基于数学模型和先进控制理论的新技术在技术要求上比传统自控技术更加复杂，所以自控的硕士生开始抢手，博士工程师也时有所见，但博士工艺工程师依然是凤毛麟角的。这也说明了一个问题：纯分布式管理所要求的小而全不再合适，人力成本太高。关于先进自控的兜售问题已经另文叙述，但APC在项目阶段，由集中的专业队伍负责实施，还是有一定的优越性的。问题是必须把基层自控队伍结合进来，不光是名义上的结合，还要实质性的结合，确保ownership。必须清楚的是，“中央军”只是雇佣军，山大王才是主人翁。

: A0 p; \5 i. d5 F3 N如果说常规自控好比大众的话，4S已经是一笔不菲的开销了。但先进自控好比大奔S级，高端大气上档次，但4S更加厉害。要维持先进自控的效益，不仅要经常调试，还要不断监测性能变迁，必要的时候更新数学模型，这就相当于重做半个APC项目了。在系统层级，也要不断升级更新软件，补漏洞，引入新功能。这是很大的工作量。系统升级之类可以集中管理，但日常维护、调试就必须是扎根基层的分布管理了。事实上，APC成功的关键不在最初投运时有多少厉害，而在于转入日常使用后是否会继续发挥作用，这只有分布管理才可能做到。如果说其他专业还有相对明确的分布式为主还是集中式为主的问题的话，自控专业必须是分布与集中相结合。

APC队伍需要很多非常专门的技能，但基层自控工程师需要扎根基层。前者划入集中部分，后者划入分布部分。问题是，如果公司非常大，不断有新的APC项目需要做，养一支专业的APC队伍是合理的。但项目做完了，再养一支专业APC队伍就浪费了。一般做法是在需要做APC的时候，外包给专业公司，通常是提供APC软件的公司的技术服务部。在理想情况下，他们做过类似的过程；这样你就不必成为“学习的代价”了。但开路先锋也有好处，不光是在业内首先获得相关的APC收益，外包合作方通常也特别迁就，有求必应，他们也在学习的过程中，不会放弃每一个学习的机会。但通常的错误是，由于用户缺乏经验，APC项目基本上全盘委托给外包公司，用户方只管提供钱和“协助”。这有几个很大的问题：
5 Y1 ^5 e9 Q, |3 E5 _2 h' O1、        外包方对于同类过程有一般认识，但对于具体过程的个性不清楚，而恶魔就在细节之中
$ K# P+ {2 x8 u2 s; j' ]0 Y' t, L2、        外包方主导设计和实施，用户方只是被动配合，缺乏ownership，对日后维修、升级都不利
3、        一旦出现产品换代、过程参数变迁、设备更新，需要模型更新，又需要把外包方请回来重做一遍
! T( z- p- P$ B' `4、        日常调试也经常需要求外包方，反馈慢，收效差
外包方主导的话，项目完成撤走之后，很少有能维持APC收益的，在线率通常直线下降，两年后差不多就被丢到一边不用了。要改变这样的现象，只有用户方主导设计，外包方提供咨询和具体技术支持，比如软件的使用和常见问题，但这又需要加强驻厂的基层自控工程师的力量和素质。这有点像家居装修，包工队有经验，对于什么样的房子、什么样的一般品味要求和开支水平需要做什么样的活是有数的，但业主一定要牢牢抓住设计、用料、色彩，在施工的每一步都密切跟踪，确保包工队与业主对于同一个要求和细节的解读是相同的，而不是到收尾的时候算总帐，那样必定有遗憾，只是遗憾大小的差别。很多时候，在施工的时候只是很小的变动，对包工队也没有多少额外的工作量，只是他们没有意识到原来你要的是这样的，这是只有全程参与、及时沟通，才能最后达到业主的要求。

对于中小型公司，维持专业APC队伍有困难的话，比较合理的做法是立足于分布式模式，借助于外包的技术支援，填补专业技能的空缺，但还是要坚持以我为主，不能搞委托制。但公司还是要有一个集中负责的，这个资深自控工程师需要有与外包方相当的APC经验和技术素质，但由于不牵涉到日常基层自控支持，有时间对APC软件深入研究和掌握。这个人不仅对APC 项目富有领导责任，还附有教育、辅导和技术支援的责任。基层自控工程师职责繁多，不可能都达到对APC软件熟练运用的程度，通常只掌握够用的就行了，有时就需要“中央军”支援了。中央军还负责对新技术的评估、与供应商的谈判等。
8 N0 \( p6 j6 m
0 W# k0 M* i" n5 S  u这样说来，自控这一摊还是分布管理为主，但有一个非常小而精干的“中央军特种部队”。更具体地说，不管是DCS级还是APC级，自控应用的owner都是基层，而不是“中央军”，中央军只是提供高层次技术支援的。