4. AF层级结构搭建
AF（Asset Framework）的核心价值在于把分散在PI Data Archive中的测点，按物理资产或逻辑功能重新组织成一棵可导航、可继承、可复用的树。这棵树不是简单的文件夹嵌套，而是一套带语义的父子关系模型：父元素负责定义通用属性与模板，子元素负责承载具体实例与测点引用。层级搭得好，后续的模板复用、分析计算、事件框架和通知才能顺畅落地；层级搭得乱，后期维护成本会成倍增加。
一、层级设计的基本约定
在动手建树之前，先明确命名与分层约定。推荐采用“企业 → 工厂/基地 → 装置/产线 → 单元/工段 → 设备”五级主干，但并非所有场景都必须凑满五级。判断标准是：每一级是否承载了独立的属性集合或独立的分析需求。如果某个中间层没有任何专属属性、也不做独立计算，就应合并，避免出现只有名字没有内容的“空壳层”。
命名建议使用“类型前缀 + 业务编码 + 中文名”的组合，例如 PLT_01_常减压装置、UNT_02_催化裂化反应单元、EQP_P-101A_原料泵。这样在AF Explorer中排序、搜索和批量引用时都能保持稳定。元素名称一旦被分析、通知或外部报表引用，修改成本很高，因此编码规则应在建模前冻结。
二、父-子关系的建立与模板继承
AF中父子关系通过元素的Parent属性确定。新建元素时指定父元素，即完成挂接；也可以先建好一批元素，再通过拖拽或批量导入调整父级。真正决定层级“智能程度”的是模板继承：在父级元素上引用一个Element Template，子元素继承该模板后自动获得属性定义、默认值和关联的分析。子元素可以覆盖属性值，但不能删除继承来的属性结构。
典型做法是：在“设备”层为每类设备建立模板，例如离心泵模板包含额定流量、额定扬程、设计压力、PI点：入口压力/出口压力/电流等属性；在“单元”层建立单元模板，包含单元编号、所属装置、运行状态等。这样新增一台泵时，只需选择模板、填写覆盖值、绑定测点，几分钟即可完成，而不必逐条手工建属性。
三、多归属：一台设备属于多个父节点
实际生产中，一台泵可能既属于“反应单元”的工艺归属，又属于“公用工程”的维护归属；一条管线可能跨越两个装置。AF允许一个元素拥有多个父引用，但物理元素本身只应创建一次。推荐做法是：选择一个“主归属”作为元素的Parent，其他归属通过Reference（引用）挂接。Reference不复制元素，只建立指向关系，因此测点绑定、属性值、分析结果始终唯一，不会出现两个副本数据不一致的问题。
如果业务上确实需要“同一设备在不同视图下呈现不同属性”，例如工艺视图看流量、维护视图看振动，可以通过在引用节点上附加不同的属性映射或分析来实现，而不是复制元素。复制元素是AF建模中最常见的反模式，它会在后期造成测点重复绑定、报警重复触发、报表口径不一致等连锁问题。
四、共享节点的治理要点
共享节点通常出现在公用工程、管网、罐区、电气系统等跨装置对象上。治理时把握三条原则：
- 单一数据源：共享设备的PI测点只绑定一次，所有引用位置通过属性继承或引用读取，不重复绑定。
- 明确主归属：为每个共享节点指定一个主归属父级，通常按“谁负责日常运行监控”来确定，其余归属用Reference表达。
- 变更影响评估：修改共享节点的模板、属性或测点前，先通过AF的“Where Used”功能查看所有引用位置，评估影响范围后再执行。
五、一个可参考的建模检查清单
| 检查项 | 判断标准 | 常见问题 |
|---|---|---|
| 层级深度 | 每级都有独立属性或分析需求 | 出现无属性的空壳层 |
| 命名规范 | 类型前缀+编码+中文名，全局唯一 | 同名元素导致引用歧义 |
| 模板继承 | 同类设备使用同一模板 | 手工建属性，结构不一致 |
| 多归属处理 | 物理元素只建一次，其余用Reference | 复制元素导致数据分叉 |
| 测点绑定 | 每个PI点只在一个元素上绑定 | 同一测点重复绑定到多个元素 |
| 共享节点变更 | 变更前用Where Used评估影响 | 直接改模板导致下游异常 |
层级结构搭建完成后，建议用AF Explorer的树形视图和“Where Used”功能做一次全树巡检：确认没有孤立节点、没有重复绑定的测点、没有指向已删除元素的悬空引用。这一步通常能发现80%以上的建模问题，且成本远低于后期在分析或报表中排查数据异常。