大规模 SCADA 工程的点名规则与工程模板
第一个月随手起的点名，会变成后面每一次改动都要交的税。大规模 SCADA 工程很少栽在第一张画面上，真正出问题的时候，是第二条线要接入、报警一览要导出、新来的承包方分不清某个点到底对应哪台电机。离散制造车间是这样，厂务机房也是这样。这篇文章整理点名混乱在后期的代价、命名规则必须覆盖的字段，以及为什么 I/O 分配、点表和画面规格书要在画图之前就落地。
点名混乱会在后期付什么代价
- 重名与撞名：两座站都叫 Pump1_Run，报表混在一起，事件出来后分不清是哪个现场
- 画面与点名各说各话：画面上的显示名被改过，底下的点还是电工随手写的缩写，排障要同时会两套词
- 报警文本无法从点名生成：每条报警说明都是手打的，工艺侧一改名，报警一览永远对不上
- 扩建把混乱一起复制：下一个区域按第一个区域克隆，坏点名一并带过去，多一条线就多一笔清理成本
- 移交变成口口相传：只有当初的工程师知道 T12 是 A 泵出口温度，而那个人已经不在现场
这五笔代价都出现在调试之后，而不是调试之中，所以容易被往后推，也特别难事后翻盘。命名规则在第一周定下来成本很低；画面已经上线再去改几万个点，就不是同一量级的工作。
命名规则要覆盖的字段：区域、设备、信号、类型
命名规则不是审美问题，而是一份契约：每个点、每条报警文本、每个画面对象都应该能从这套字段推出来。缺一个字段，后期脚本就没法按区域过滤，没法生成报警文本，也分不清这是工艺值还是命令。
下面四个字段是创建第一个点之前就要定下来的下限。分隔符、长度和字符集也要写进同一份规则，因为混品牌 PLC 和后期的数据库导出，都会惩罚不规范的拼写。我们在单个工程里做过近 80000 变量、366 台设备同网联网的采集。这个数字描述的是具体项目，不是典型工程规模，也不是对每份合同宣传的点数上限。它说明的是：规则必须在点数变多时仍然成立，而不是只在中试线几百个点时好看。
- 区域（厂区、产线或建筑）：资产在地理上归谁——工厂、车间、产线或泵站编号。没有它，两座厂房里型号相同的设备会撞名
- 设备（机组、撬块或单机）：资产本身——压缩机、输送机、泵组——好让同一台设备的信号排在一起
- 信号（测量值或功能）：读的或写的是什么——运行反馈、出口压力、故障、设定值
- 类型（点类别）：模拟量入、模拟量出、开关量入、开关量出、计算点、报警点、设定值——好让历史库、画面和报警引擎按点的性质处理
- 分隔符、长度和字符集：只用一种分隔符（下划线是常用做法），长度取最短的那台 PLC 和历史库都能接受的值，点名里不放空格和会破坏导出的本地标点
工程模板要先于画面：I/O 分配、点表、画面规格书
画面是 SCADA 工程里看得见的部分，所以讨论往往从画面开始。大规模工程要把这个顺序倒过来：I/O 分配、点表、画面规格书必须在画图之前存在。缺这三份，后面每张画面都在当场发明点名，运行中的系统也就没有可对账的真源。
在上述采集规模之外，我们还在近 30000 报警点的工程里做过报警工程化。这些数字是具体项目的实证，不是默认每个现场都有这么大，更不是把软件宣传里的点数承诺套到每份合同上。某一网段的点数上限，由带宽、轮询周期和服务器余量决定，写进下面的模板里，而不是等到调试时才发现。
- I/O 分配表：柜号、槽位、通道、信号类型、工程量程和目标点名，在 PLC 编址开始之前冻结
- 点表：真源——点名、描述、区域、设备、地址、数据类型、扫描等级、工程单位、报警标记。一个点一行，文件只有一个责任人
- 画面规格书：有哪些画面、绑定哪些点、导航和报警呈现怎么做——写在画图之前，而不是画完再补
- 地址与网络图：哪台控制器占用哪段地址、同一网段有多少设备，以及该网段在约定轮询周期下的点数上限
坏命名、它造成的问题、推荐结构
下表是一份可拿来用的核对清单，不是通用标准。第三列的结构是 区域_设备_信号_类型。四个字段按本厂填实，再冻结拼写、分隔符和长度，后面每一次导入都走同一份契约。
| 坏命名 | 造成的问题 | 推荐结构 |
|---|---|---|
| 同一工程里混用 Pump1_Run、Pump1Run、P1R | 同一信号三种写法，检索和脚本会漏掉其中两种 | 一种结构、一种分隔符，例如 P2_PU01_RUN_DI（区域_设备_信号_类型） |
| T12、AI03、MtrA | 只有原作者解得开的代码，移交依赖记忆 | 点名里带上区域和设备；含义放在描述字段，不要藏在私有代码里 |
| Line2_Temp 既当工艺值又当报警 | 历史库、画面和报警一览抢同一个点，过滤器分不开 | 工艺点和报警点分成两个点；用类型字段区分 PV 与 ALM |
| Compressor_Discharge_Pressure_High_High_Alarm_SP | 点名超出 PLC 和历史库长度，截断后会静默撞名 | 规则里限定长度；限定词放进类型和描述，不要堆成超长字符串 |
| 同一张表里 1号炉_温度 和 Furnace1_Temp 混用 | 导出、OPC 路径和 SQL 查询会被本地字符或空格打断 | 点名只用一种语言（英文标识符是常用做法）；本地语言放在描述里 |
推荐结构是起点模板。字符集、长度，以及区域、设备的具体编码，要和现场一起按实际使用的 PLC 品牌和历史库来定。
报警点与工艺点要分开治理
工艺点回答的是「现在是多少」。报警点回答的是「有没有人必须动手」。几百个点时把它们做在同一个点上显得省事，到几千个点就管不住。报警一览会把工艺点表里所有图省事的命名一并继承下来，后面再做治理时手里没有干净的清单。
分级、抑制和复位归档是另一套设计，我们在 SCADA 报警治理那篇专栏里写过，本节不重复那套分级教程。这里要定的是让后面那项工作能够开展的前提：两套点群、两个责任人、一份能从区域、设备、信号生成报警文本的命名契约。
- 点群分开：需要报警的工艺点配成对的报警点，或按点名关联一条报警记录——不要做一身两用的点
- 报警文本从命名字段生成：区域、设备、信号拼出可读说明，改名时点和文本一起更新
- 责任人分开：工艺点跟 I/O 和历史库走，报警点跟运行走，带等级和关闭规则，两张清单按不同节奏复盘
- 不要把报警等级写进每个工艺点名：等级属于报警记录。把 HH、H、L、LL 写进成千上万个工艺点，一次重新分级就变成大规模改名
在近 30000 报警点的工程里，真正撑住的是这套分治，而不是更大的画面。多数工厂到不了这个数量。几百条报警时就把点群分开，仍然值得做，因为那时成本还低。
总结
大规模 SCADA 工程靠点名和模板治理，不靠第一张图。先定字段——区域、设备、信号、类型——发出 I/O 分配、点表和画面规格书，并把报警点从工艺点表里拆出去。跳过这些步骤，后期付出的不是画图，是改名。
如果点名已经混了，先导出在线点表，把撞名和缺字段列出来，在下一个区域开工之前冻结规则。在规则下多接一条线，比事后清理整厂便宜。