一座拥有 2,400 台仪表的化工厂 — 每台仪表都需要组态、报警、历史记录和 HMI 面板分配 — 可以用两种方式完成工程实施。基于标签的方式逐台配置仪表：2,400 次走同一套组态流程，2,400 次让技术人员把报警限值设得略有不同的机会，以及当企业报警策略变更时需要逐一更新的 2,400 个点。面向对象的方式只定义一次压力变送器类 — 连同其报警模板、历史记录策略和 HMI 面板 — 然后为工厂中的 800 台压力变送器实例化 800 次。当报警策略变更时，只需更新一次类，全部 800 个实例即继承该变更。本文从初始建设工作量、生命周期维护和跨项目复用三个方面比较这两种工程方法。
面向对象工程与基于标签的工程在数据库层面的差异
在基于标签的工程方式中，控制系统数据库是扁平的。每个标签都是一条独立记录，拥有自己的一套属性 — 量程、报警限值、工程单位、扫描周期、HMI 画面分配 — 逐一配置。标签之间唯一的关系，是工程师在单独的电子表格或设计规范中自行维护的那种关系。如果同一反应釜上的两台压力变送器应当具有相同的报警限值，工程师必须记得将它们配置得完全一致 — 这一过程完全依赖人的自觉与同行评审。
在面向对象的工程方式中，数据库是分层的。一个类（或模块，或资产类型）为某一设备类型或控制功能定义完整的组态模板。实例从其类继承全部属性，但可以在应用需要时覆盖特定的值。这种继承是实时的 — 把类报警限值从 95% 改为 92%，所有未显式覆盖该值的实例都会自动更新。这正是 DCS 平台沿用数十年的工程模型，如今在现代 PAC 和 SCADA 平台上也越来越普及。Emerson PACSystems RX3i CPL410 支持模块化、可复用的控制库，把面向对象的工程理念带到 PAC 层 — 弥合 DCS 风格工程方式与 PLC 风格执行速度之间的差距。
面向对象工程回报最大的场景
面向对象工程最有说服力的场景，是设备类型高度重复的工厂。一座拥有 200 台温度变送器、150 台开关阀和 80 个 PID 回路的制药厂，会把每种设备类型配置为一个类，然后实例化其成员。初始建设工作量的节省 — 对于 I/O 点数超过 500 点的工厂，相比基于标签的组态方式大约节省 30–50% — 是实实在在的，但更大的收益出现在运行阶段。当工艺安全评审要求把每个高高压力报警的报警延时从 2 秒改为 1.5 秒时，采用面向对象方式的工厂只需更改一个类属性，该更新便在全系统范围内传播。而基于标签的工厂则需要技术人员打开 80 个独立的标签组态 — 80 次漏掉其中一个、从而造成潜在安全偏差的机会。
跨项目复用是第三个回报来源。一家工程承包商若用面向对象工程方式建设三座相似的沼气厂，就会把第一个项目的类库复用到第二、第三个项目 — 后续每个项目都不是从空白数据库起步，而是从一套经过验证的设备与控制类库起步。第一个项目之后，工程工时急剧下降，各厂站之间的一致性也简化了业主的维护培训。我们原生支持面向对象工程的 DCS 平台，以及具备模块化组态能力的过程控制器，可供参考。
基于标签的工程方式仍然适用的场景
对于小型、一次性的系统，基于标签的工程方式仍然适用 — 一套 40 个 I/O 点的成套撬装设备、一台 25 个标签的单机改造、一个实验室试验台。在 I/O 点数大致低于 150–250 点，或某一给定设备类型的实例少于 3–5 个时，定义类的开销会超过组态本身的工作量。低于这个阈值，类定义的工作量无法由实例数量证明其合理。当每台设备确实都独一无二时，基于标签的工程方式也仍保有一项优势 — 例如一个 R&D 中试装置，50 台仪表每台都是不同厂商的不同类型，没有任何重复。但这种情况在生产制造中很少见，因为设备类型的标准化本身就是可靠性与可维护性的最佳实践。
面向对象工程并不是一项新技术 — DCS 平台自 1980 年代起就在使用它。变化在于它已走出 DCS 领域而随处可得，这使它成为任何拥有数百个以上 I/O 点、且设备类型重复的项目的相关选择。
