一 OPC结构概述

众所周知，从计算机技术介入到工业（控制）应用领域开始，伴生的“信息孤岛”问题就一直困绕着业界。“信息孤岛”相当严重地限制了信息交换继而约束了应用领域的拓展。“信息孤岛”问题概括体现在用户（应用）程序对数据的访问，一是从信息源获取什么样品格数据（包括类型—信息类型与数据类型，品位—好、坏、不定，以及时标等），二是如何把这些数据信息从源（地址）送达目的地。期间，为解决“信息孤岛”问题也曾作过多种尝试。例如ISO就数据交换（通信）制定了OSI（开放系统互连）的7层模型，来描述、表达数据传输及表示的属性与要求。但是，它不是一种标准或规范。就7层模型的下面4层一物理层、链路层（网络层及传输层）而言，据此进行数据传输的通信协议的现场总线控制系统FCS就多达8种[1]，使人们莫衷一是[2]。至于7层OSI中的表示层与会话层，在DCS及PLC中基本上不予采用。但据笔者理解，正是OPC基金会将这两层的功能作为基金会的规范予以确定，为用户提供了一个统一的系统平台。

图1 客户应用程序与多个OPC服务器（程序）联同工作

如图1所示，OPC服务器程序A、B、C分别代表譬如FF的设备供应商提供的服务器(程序)，PROFIBUS的服务器与CONTROLNET的服务器，其与应用程序X、Y交换数据的品格符合OPC规范；同样，应用程序（客户端）需读、写的数据品格也符合OPC规范。这就相当于III型仪表中的记录仪、变送器、调节器等均按4~20mA或1~5V的标准制作，这样不但不受其制造厂商约束而任意组合配置，而且还可即插即用。对客户而言，它只需按规范规定的数据品格与服务器交换数据，而勿须关注其数据来往的细节（例如硬件设备与通信规约）。至此，对客户端而言，其系统平台是统一的。对设备制造商而言，它所制造的设备的信息用户有了规范可依，也就勿须逐一制订适合不同应用的驱动软件，相形之下也就事半功倍而何乐不为呢？正因为如此，OPC规范深得用户与制造商的欢迎。就用户而言，无须对目前FCS的多维局面而杞人忧天!

图2 典型的OPC结构图

典型的OPC结构如图2所示。当作为客户端的应用程序需访问在不同数据库的数据时就借助OPC服务器予以进行。这种OPC服务器是由提供所使用设备的制造商作为一揽子产品予以提供的。诚然，该服务器在同客户端应用连接之前，不但需提供客户同步或异步读、写数据要求的能力，而且还需逐一询问所访问数据的目的地址(例如站号、设备或参数工位号及标识号等)、数据品格(品格指数据的类型、尺寸、质量、时标等)、访问速率、是同步读写还是异步读写、访问群组(group)及每一群组内的参数数据等组态或配置数据。OPC服务器据此按每一群group安排线程，每一个group内所包含的参数数据由服务器分解为一系列Item，如图3所示。例如，一个记录型数据(Recode)包括一个Status(Un8)及Value (Float，4byte)，则Status与Value就各构成一个Item，即Recode或ARRAY有多少子项，则每一个子项都构成一个Item。至于每一数据或Item的含义则一概不予过问。据此，一个服务器就是按多线程调度实施的智能开关，按要求接通数据的源与目的地址，至于是同步读写还是异步读写，则由客户应用确定。例如，进行批处理或配方处理时常要求异步读写。图1中在X、Y中的OPC Interface等同于图2中的OPC Automation Interface及/或OPC Custom Interface。它的功能可大致理解为远程通信打包、拆包。服务器对于传输的数据含义一概不知，然而在这种Interface中就需赋以含义了，这就是笔者把OSI中7层模型中的表示层与会话层折同于此的依据。其中，OPC Automation Interface可由OPC基金会一个标准的自动接口搭扣(wrapper)实施平常的接口转换，而OPC Custom Interface则在需刷新或更改接口功能时予以使用。

图3 群组Group/Item关系图

综上所述，按OPC基金会的规范，各设备制造厂商连同实际设备与相应的OPC服务器(程序)成套供应，与客户应用(程序)打交道的，只是规范了的数据，这就是OPC为客户应用端提供全开放的统一系统平台的基本思路! 无疑，为争取市场，各制造厂商会致力于相应OPC服务器的开发实施。据悉，National Instruments(NI)公司已有适合FF规范的OPC服务器问世。顺便提及，OPC规范尚有待进一步完善升级，当应用需求的数据品格不在现有规范之列时，可以Byte ARRAY的数据格式代之，而用OPC Custom Interface予以赋义解释。

二 FCS统一体系结构

笔者在文献[1]中详述了FF-H1两种设计思路所形成的体系结构。把I/O点分散予以数字化再赋以智能化的H1园卡思路就仪表智能化而言是可取的；然而就构成控制回路而言则难以恭维；它还不如现已从人们记忆中淡忘了的单回路数字调节器。后者构成一个闭环控制单回路或一个简单串级控制回路勿须借助通信就能实施。这种分散到无以复加而必须把PV值从变送器借助通信按时送到阀门上的H1园卡才能进行闭环控制运算，不但加重了通信的负荷，更增加了其复杂程度。形成闭环控制的及时性(Timelines)要求必须进行实时性的强制通信，随机性的不时之需的人机操作及/或修改以及传送报警与历史趋势要求的三种通信要求无疑使通信复杂化；逐点分散构成一个控制系统就必须统一号令——统一时钟与调度，即LAS；而为了控制的可靠性则必须对现行LAS者有冗余措施，而且这种冗余是在线冗余或称任务冗余，其技术难度远大于常规的离线冗余(Back-up)。凡此种种，均是由逐点彻底分散而酿成的。

笔者对仪表数字化、智能化并无贬意。无须赘言：要智能化必须先数字化。文献[2]提到无A/D、D/A而提高精度，这种提法欠妥。事实上，就测量而言，非电量变成电量几乎全是模拟值电量，将此微弱电平经前置放大后（1伏电平左右）直接进行逐次比较型的A/D转换，与对4~20mA或1~5V输入进行A/D转换比较，只不过是避免了中间级或后置放大的误差而已。至于数字化以后的智能化，则全是软件考虑了，这就有赖于“仁者见仁，智者见智”。

如文献[1]图8所示，把DCS控制站整体搬至现场的局部集中体系结构将是FCS的主流结构，除已述之外尚有以下特点：

(1) 控制站的控制功能与构成系统的性能及采用通信协议是各自独立的，因而已为现行各种通信协议的FCS所采用。

(2) 把DCS与PLC在结构形式上予以统一。长期以来，人们一直把DCS与PLC予以区分，这其实是一种误解。事实上，两者均是可编程控制器，只是PLC多偏重处理开关量，大多进行逻辑运算，因而价格较之DCS便宜一些。然而，随着PLC处理模拟量能力的增强，两者在功能上已难分伯仲了!反之，倒是结构与安装上不同而使人们仍加以区分。一般，DCS多是大机柜安装在控制机房内，而PLC常挂壁安装 ，如该图下部所示，FCS在外形、安装上已消除这种区分了。可能有人会问，控制装置的生命之泉——电源如何考虑？使用现有的24V仪表电源或高于12V的电源并以12V的蓄电池与之并联供电就可简单解决。

(3) 该控制站是局部集中控制的，当无Timelines要求时，可采用以太网予以联网通信，这已为各种标准的FCS所认同。这样，从物理层至链路层采用以太网协议，而网络层采用IP，传输层采用TCP或UDP。OPC服务器主要引入DCOM技术，后者使得基础的网络通信协议对OPC客户机/服务器透明。DCOM可以使用如UDP、TCP/IP和IPX各种传输工具发送信息，DCOM使用的是相同的OPC应用程序。如此，不但OPC就交换数据信息而言提供了一个全开放的统一系统平台，而且连具体传输信息的通信协议也都采用以太网+TCP(UDP)/IP了!这在具体实施上也都趋于一致，无疑极大方便了用户正常的维护处理。

然而，就以太网的应用，笔者还有一些逆耳之言。早在1991年，国产第一套DCS——友立2000在沧州炼油厂FCC装置投运时，笔者就实际体会过。该系统的MMI—操作站与控制站就用全输速率为10M的以太网联网，各控制站之间无Timelines要求的信息要交换，而且该局域网总共站点数小于10个，其使用相当成功！但是，近几年来，以太网成了大热门，并企望一网到底，甚至像FF-H1那样赋予本安性能。笔者不但在[1]中，而且还在上面再次阐明：就IEEE802.3规约而言，随机取得通信权的以太网通信不能满足有Timelines要求形成闭环控制回路的需求。通信全输速率即使达到1G，但最大1024个网站的局域网中若有300个I/O点各自都作为网站需要抢通信权的话，其碰撞是无法避免了，这有损于闭环控制。 可能有人争辩说，可采用优先级，但是，优先级多，就无优先可言了，这也不是IEEE802.3本意。至于采取其它措施，例如HUB(集线器)等，则成本上升，采用以太网的优势也就减弱了，另则能否安装于工业现场？笔者对于以太网传输距离在100m以内能否应用于工业现场已心存疑虑了，至于一网到底乃至在国家已经多处立项进行攻关开发，实在是感叹不已!笔者可能不幸而言中：最终只可能一纸报告交帐了!

三 FCS的竞争将聚焦于应用软件的竞争

取决于应用软件，而整个系统的可靠性也与应用软件的可靠性息息相关。笔者在文献[3]中赞同文献[4]的观点而在此处延伸至FCS:FCS的竞争多半取决于谁能拥有解决复杂控制问题的先进软件。

笔者长期从事石油化工生产过程计算机控制的开发应用，对此感触甚深。应用软件有稳态优化、先进控制及基础控制软件等，而其能否取得实效则在更大程度上取决于对生产过程的了解深度。

近些年来，按长官意志办事变相“强行”推销国外优化、先进控制软件的事，笔者有亲身体会。然而，大多都象“保健品”那样效果难以言明。投入不少而效果不大的原因，笔者分析主要有以下几点：

(1) 对生产工艺及其控制要求并非十分了解而应付之事有之，例如对渣油汽化工艺一无所知的某外国软件商拿到合同后向笔者咨询之事令笔者嗤之以鼻；某厂优化及先进控制项目仅由外商以合同金额叁千分之一不到的代价装了两台微小量程的H2流量计使操作工有据可依而获效益；搞FCC（催化裂化）优化先进控制开发者不知回炼比降低是否是效益的直接体现。

(2) 优化或先进控制的目标不符合要求，例如，大多炼厂炼量不足，而指标却是处理量最大而不是轻油收率最高等。

(3) 优化的指标大多是稳态指标，然而实际生产过程不是因原料变化（例如原油供应变化）或加工方案变化或其它原因而常处于动态过程之中，就是稳态时间太短，致使指标游移不定而收效甚少。

自从DCS介入过程控制以来，国内对DCS的使用大多停留在代替常规仪表的水平上，如何充分发挥其潜力或开发一些新型控制算法有针对性地解决诸如炼厂原油切换带来波动、缩短切换动态过程等则基本上无人问津，绝无立项啃这种“硬骨头”的，而且也不可能为解决生产实际问题在国家立项攻关的。大多均因水平低无多少高深理论、数学推导而不屑一顾！事实却不然。以笔者致力于大型氨厂一段转化炉水/碳控制系统的开发、设计、实施[5]而言，深深体会到：只有比工艺人员在某些方面对工艺及控制要求的了解程度还深，才能搞好基础控制与先进控制。该系统国外原设计十分差强人意，常导致全厂联锁跳车！笔者曾针对四川化工厂、大庆化肥厂及齐鲁二化现场提出按预联锁概念设计控制方案，但三个厂的原料气供应不一样而又作不同的具体处理，以后者的设计实施方案[5]最为完备，完全解决该厂因原料含碳量波动而带来的生产问题。这其中，按实际负荷与标称负荷，以及返氢量的扣除等概念的使用与计算，是笔者对该生产工艺了解的深度出乎于工艺人员意料之外，该系统在现场投运大获成功而长期交付使用。但是，某博士生导师此后在某现场投运同样系统时却招致全厂联锁跳车。此处并非揭人之短，而只是想说明这样一个问题：解决实际工程问题并非不屑一顾之易事，尚宜正视之而不要回避！

文献[5]中提到，该系统在现场投运之前发现了该DCS中某种功能模块的问题后，反映至该公司总部未获答复，后来笔者在自己开发的功能模块中发现问题所在后轻易而举地解决了。同样，赋予预联锁功能的控制系统对实施控制算法的功能模块有逻辑量同步处理要求，据之开发的功能模块应用软件岂不是有其独到之处。笔者设计这套控制系统当时使用C3变字长浮点运算使控制站的时空开销大增，原本可以使用255个功能模块的，但实际只使用80个模块就无Free Time了。当然，这对现在CPU芯片而言已不成问题了。另外，据笔者体验：DCS或新型FCS，其中应用软件—功能模块如按OPC标准有互操作要求的话，其难度与复杂程度远超过原有的。而且，互换性测试通过了，未必其可靠性就不出问题。上面提到Y公司DCS控制模块问题，在20吨快锅（大修后开工先投运）点火不到2小时就导致熄火！所以，对控制算法的功能模块必须要由有工程经验者逐一仿真调试，应做到万无一失才可找一个现场测试投运，到现场考核是绝对不允许调试改程序的！这就是开发控制功能（模块）程序难点所在。还因为如此，其它计算机软件都有升级换代的，唯独只有控制功能模块无升级换代，常见的只有功能模块扩充或引入新的功能模块。例如，Y公司功能模块尽管扩充了很多，但类似于常规仪表的4个端子结构一直沿用其现有DCS产品。

四 建议国内业界致力于FCS系统集成

目前，扬长避短进行新产品开发事例屡见不鲜。就FCS而言，国外一些著名厂家并非全部自行开发研制，在其发布的新产品中采取“拿来主义”——购买OEM产品甚或买断性及/或委托开发部件再予以集成成自己品牌的系统者并非罕见。然而，我国以往并非如此，而是由国家出钱作为攻关课题予以大包大揽。一些扯着大旗当虎皮者在申请立项争钱方面尽显其能事。结果，花了国家几千万搞FF（H1园卡）产品及HART产品，在“九.五”期间未见产业化，“十.五”再追加！反过来，如若花这些钱委托国外厂商开发或合作开发，则早已产业化了！事实上，H1园卡是装在变送器及阀门上的，试问国产变送器有多少？而合资的绝不会采用国产H1园卡！这种几千万的攻关立项论证过吗？论证的专家学者是不懂还是“走过场，装糊涂”？未获国家任何资助一民营企业则早已将HART协议产业化并首先通过该基金会认证，那些拿了超过买断性委托开发所需费用一倍以上的国家拨款者该如何交帐？这其中是否有学术腐败？

往者不可谏！建议国内业界有识之士与企业购买OEM产品予以系统集成为自己品牌的产品参与市场竞争。这一建议是基于以下考虑。

(1) 全开放的FCS其应用（层）程序与包括硬件与系统软件（内含通信部分）的系统平台已可彼此完全独立，能够任意选购不同厂家的系统平台予以即插即用，因而进行集成在技术上无任何障碍。

(2) 购买OEM产品，或是成为该厂商的系统联盟商，利用其作为OEM产品的系统平台集成自己品牌的FCS能扬长避短，争得投入市场的时间。事实上，FCS产品的系统平台包含许多高新技术，技术复杂，完全自己开发已被证实在目前无此可能。“九.五”课题国家投入巨资，组织国内各有关单位、企业会战5年，结果如何呢？从NI公司买了开发工具历时5年以上还无法在H1园卡上实现LAS。现实情况是，国内工业用的计算机硬件产品打开市场难度大，用国外的系统平台与国外产品竞争就可平起平坐一争高低了；而且系统平台的更新、升级全由OEM厂商考虑，因而该FCS系统产品就可永远处于国际先进水平。

(3) 国内从事工程应用还是有力量的，其中从事应用软件开发力量只要予以发现重用，在经验与知识水平上完全不亚于国外系统集成厂商的系统工程师；至于从事工程应用的技术力量则更不成问题。

(4) 最重要的是集成产品的利润如何呢？据笔者初步了解，从国外专门从事OEM产品生产的公司，例如NI公司购买一套装备FCC的FCS系统平台，其售价只有现行DCS的1/3不到，这还不包括作为其联盟商大批量可享受近50%的价格优惠。

(5) 只要不大的一次性投资把应用软件——功能模块挂到系统平台上，联成一套FCS系统，之后几乎不要什么投入，仅需按定单配置系统即可。

“仁者见仁，智者见智”，笔者相信业界有识之士会认真考虑这一建议的。事实上，国内已成品牌的某DCS公司也是沿集成道路走过来的，期望国内FCS集成品牌早日面市。