OntoFlow 本体智能平台在污水处理厂的应用

基于原生Ontology结构的污水处理运营驾驶舱

业务世界模型 · OntoFlow 本体工作流 · OntoX 孪生 · OntoOS 推演

污水处理厂的数据并不少：进水水质、出水水质、工艺参数、设备状态、药剂、能耗、实验室化验、告警与事件......真正困难的并不是"把这些数据展示出来"，而是回答：

现在污水厂到底怎么样？为什么出现风险？风险会影响什么？应该采取什么动作？动作之后状态有没有改善？

OntoFlow 的做法不是再做一个污水数据大屏，而是把已有数据组织成一个可计算、可推理、可行动的污水处理 Ontology 世界模型。

本文以一个正在落地的污水处理运营为例，介绍如何从一批业务数据出发，逐步构建一个可以被 OntoX 监控、被 AI Skill 查询、被 OntoOS 推演的本体应用。

一、先不要建本体：先回答三个问题

构建本体应用，最容易犯的错误是：

一上来就设计几十个实体、几百个属性。

更推荐从业务目标倒推。

可以把整个过程概括为：

text 复制代码

我有什么？
    ↓
我想解决什么业务问题？
    ↓
什么对象真正参与这个问题？
    ↓
对象之间有什么关系？
    ↓
哪些状态可以计算？
    ↓
哪些动作可以改变状态？
    ↓
动作之后如何验证结果？
    ↓
形成 Ontology Application

1. 分析我有什么？

先整理出你的业务数据：

数据类别	典型数据	本体应用价值
进水水质	流量、COD、NH3-N、TN、TP、pH	判断进水负荷、冲击
工艺运行	DO、回流、曝气等	判断工艺运行状态
出水水质	COD、NH3-N、TN、TP、SS	判断最终处理结果
设备状态	风机、泵、加药设备	判断设备健康与工艺影响
加药与能耗	PFS、PAM、碱耗、电耗	分析运营成本与控制行为
告警事件	超标、故障、冲击、漂移	形成事件与风险链
实验室检测	在线值、化验值	判断数据是否可信
数据字典	指标、单位、限值	建立指标语义
工艺说明	工艺流程、处理能力	建立业务世界结构

这里真正需要提炼的不是"有 9 张数据表"，而是：

这些数据共同描述了一个污水处理厂的业务世界。

二、分析我想做什么：先给业务定一个"小目标"

本项目不追求一次做成完整的智慧水务平台，而是先选择一个可以闭环的小场景：

能看状态 → 找原因 → 做判断 → 执行动作 → 验证结果

因此，业务主线确定为：

text 复制代码

现在正不正常？
      ↓
有没有超标/风险？
      ↓
为什么？
      ↓
影响哪些工艺和设备？
      ↓
应该做什么？
      ↓
动作执行后发生了什么？

围绕这个目标，形成五个核心问题：

现在污水站运行是否正常？
出水为什么超标？
进水冲击会沿工艺流程影响到哪里？
厌氧联锁应该停在哪一档？
哪些在线数据已经不可信？

这五个问题决定后面的本体，而不是反过来让本体决定业务。

2.1 再确定一个可以真正闭环的业务场景

本案例选择：

"进水冲击 → 工艺风险 → 设备影响 → 出水风险 → 控制动作"

作为核心业务链。

text 复制代码

进水流量 × COD浓度
        ↓
COD负荷
        ↓
超标倍数 / 冲击判定
        ↓
沿 PROCESS_FLOW 传播
        ↓
A/O 工艺负荷
        ↓
叠加 1#曝气风机 FAULT + DO下降
        ↓
识别风险与根因
        ↓
生成处置建议
        ↓
执行 Action
        ↓
刷新设备 / 工艺 / 风险状态
        ↓
记录 ActionRecord

这里有一个重要原则：

本体应用不一定一开始就预测"2 小时后 COD 是多少"，但必须能够解释"当前为什么有风险、做这个动作会改变什么"。

因此，本案例第一阶段做状态级推演，而不是伪造没有动力学模型支撑的未来水质曲线。

三、把业务问题翻译成本体：不是"建表"，而是"建世界"

确定业务目标之后，再回答：

这个业务世界里究竟有哪些对象？它们如何发生关系？哪些东西会变化？哪些东西可以被改变？

3.1 核心业务对象

本案例建议保持一个相对克制的模型，只建立真正参与业务闭环的对象：

对象	顶点键	职责	为什么需要
`TreatmentPlant`	`plant_id`	污水处理厂	业务空间与全局状态
`ProcessUnit`	`unit_id`	工艺单元	描述污水处理过程
`Equipment`	`equipment_id`	设备	描述设备状态与工艺影响
`Sensor`	`sensor_id`	测点/仪表	数据来源
`Metric`	`metric_id`	指标定义	统一指标语义、单位、限值
`Observation`	`obs_id`	在线观测	描述某时刻真实测量值
`LabTest`	`lab_id`	实验室检测	校验在线数据可信度
`ProcessState`	`state_id`	厂站/单元状态	把多个事实汇总成业务状态
`Risk`	`risk_id`	运行风险	表达"可能影响业务"的风险
`Alarm`	`alarm_id`	当前告警	可确认、可闭环
`OpsEvent`	`event_id`	运行事件	表达冲击、故障、漂移等已发生事件
`ControlVariable`	`cv_id`	可控变量	明确什么东西可以被改变
`ActionRecord`	`action_id`	动作记录	留存动作前后状态与风险
`Chemical`	`chemical_id`	药剂	描述投加及消耗

这里可以看到一个很重要的设计变化：

不再把"COD、风机、告警、风险、动作"都当成普通字段，而是把真正参与业务决策的东西对象化。

3.2 最重要的不是对象，而是对象之间的关系

污水处理的业务逻辑很大一部分来自关系。

从 → 到	关系	业务含义
`ProcessUnit → ProcessUnit`	`PROCESS_FLOW`	事故池→调节池→厌氧→A/O→二沉→除磷→出水
`Equipment → ProcessUnit`	`BELONGS_TO / SERVES`	设备属于/服务哪个工艺单元
`Equipment → Equipment`	`BACKUP_OF`	1#风机与2#备用风机
`Equipment → ControlVariable`	`CONTROLS`	风机控制曝气能力
`Sensor → Metric`	`MEASURES`	COD测点测量COD指标
`Observation → Sensor`	`FROM_SENSOR`	观测值来自哪个测点
`Observation → ProcessUnit`	`AT_UNIT`	观测发生在哪个工艺单元
`LabTest → Metric`	`TESTS`	化验检测对应哪个指标
`Event → ProcessUnit`	`AFFECTS`	事件影响哪个工艺
`Risk → ProcessUnit`	`AFFECTS`	风险影响哪个单元
`Risk → Action`	`MITIGATED_BY`	什么动作可以降低风险
`ActionRecord → Action`	`EXECUTES`	执行了什么动作

其中最关键的一条是：

text 复制代码

1#曝气风机
    ↓
控制
    ↓
A/O曝气能力
    ↓
A/O
    ↓
DO
    ↓
出水风险

这样系统才能理解：

风机故障为什么会成为污水处理风险。

而不是只知道：

status = FAULT

四、把"数据"变成"状态、风险和能力"

本体应用真正区别于普通数据应用的地方，是从原始数据进一步形成业务语义。

4.1 指标不要只是字段：建立 Metric + Observation

例如 COD：

`Metric（指标体系）`

text 复制代码

COD
单位：mg/L
类型：水质指标
控制限值：......
预警限值：......

`Observation（监控体系）`

text 复制代码

时间：2026-07-10 22:00
指标：COD
值：5800
来源：INF_COD
质量：VALID

于是：

text 复制代码

Metric = "COD是什么"
Observation = "这一刻COD是多少"

二者职责分开，本体才不会变成一张"万能指标表"。

4.2 建立 ProcessState：回答"现在怎么样"

例如：

text 复制代码

PS-PLANT01
厂站状态 = RISK

并进一步形成：

text 复制代码

PU-EQ
调节池 = WARNING

PU-AN
厌氧 = STOP_REACTOR

PU-AO
A/O = WARNING

PU-PAR
出水 = CRITICAL

ProcessState 并不是原始数据，而是由：

水质；
工艺参数；
设备状态；
告警；
风险；
联锁状态；

共同计算出来的业务状态。

4.3 建立 Risk：回答"为什么值得关注"

建议把风险从普通字段中独立出来。

本案例可以形成：

Risk	主要来源	影响对象	可采取动作
`RISK-INF-SHOCK`	进水COD冲击	调节池/A/O	启动调节池
`RISK-AO-AERATION`	风机故障、DO下降	A/O	切备用/提高曝气
`RISK-EFF-COD`	处理能力下降	出水	工艺调整
`RISK-AN-UNSTABLE`	pH、产气率、负荷	厌氧	执行联锁
`RISK-DATA-DRIFT`	在线/化验偏差	控制回路	标记仪表不可信

这样一个"出水超标"就不再只是一个数字，而可以拆解为多个可解释风险。

五、让本体真正"会计算"：函数、派生与业务状态

本体应用不能只存数据，还应该从数据计算业务事实。

本案例核心计算可以收敛成几类。

① 负荷

text 复制代码

COD负荷 = 流量 × COD浓度

用于：

进水负荷；
冲击识别；
时段聚合；
工艺负荷判断。

② 冲击

text 复制代码

当前负荷 / 常态负荷 > 1.8

形成：

text 复制代码

InfluentShock = TRUE

③ 在线仪表偏差

text 复制代码

|在线值 - 化验值| / 化验值

当偏差超过业务阈值时形成：

text 复制代码

RISK-DATA-DRIFT
control_eligible = 0

④ 设备健康

设备故障风险向工艺传播：

text 复制代码

Equipment Fault
      ↓
ProcessUnit Risk

⑤ 控制变量有效能力

例如 1#风机故障：

text 复制代码

ControlVariable.effective_capacity
    ↓
下降

当前案例中可以得到：

text 复制代码

CV-AO-AERATION
effective_capacity ≈ 0.22
status = DEGRADED

这比简单说"风机坏了"更接近业务控制世界。

六、Action 不是按钮，而是本体世界中的"改变"

这是构建本体应用时非常重要的一步。

如果只有：

查询 → 分析 → 建议

最后仍然只是一个 AI 数据助手。

真正完整的闭环应该是：

text 复制代码

发现风险
   ↓
判断原因
   ↓
提出动作
   ↓
改变 ControlVariable
   ↓
刷新状态
   ↓
重新计算 Risk
   ↓
形成 ActionRecord

本案例的 Action 这样设计：

Action	目标	改变什么	预期效果	不应该假设什么
切换备用风机	1#曝气风机	设备状态、曝气有效能力	降低曝气风险	不直接修改出水COD
启动应急调节池	调节池	`emergency_mode`、进水控制	降低进水冲击风险	不直接保证出水达标
提高曝气量	A/O	曝气控制变量	提高曝气能力	无法消除风机FAULT
确认事件	事件/告警	ACK状态	完成事件处置记录	不改变工艺状态
标记仪表不可信	COD测点	`control_eligible=0`	避免错误数据进入控制	不会消除真实漂移
执行厌氧联锁	厌氧反应器	进水/碱/循环控制	执行安全联锁	不绕过联锁规则

这个表实际上就是一个非常重要的设计原则：

每个 Action 都必须明确"它能改变什么"，以及"它不能改变什么"。

这样才能避免 AI 推演变成"看起来合理"的幻觉。

七、把本体设计转成 OntoFlow 工作流

本体模型确定以后，才进入平台实施。

本案例对应典型本体工作流：

工作流节点	实际职责
开始	应用入口
数据选择	选择污水处理实时/历史数据
数据源表	进水、工艺、出水、设备、事件、化验、药耗等数据
数据处理	时间对齐、单位标准化、负荷计算、冲击识别、数据质量计算
子图建模	将数据转成 Plant、ProcessUnit、Equipment、Observation、Risk 等本体对象
本体库	写入 OntoGraph，提供查询、派生、Action
结束	形成持续运行的数据服务

这不是一次性的 ETL。

工作流本身就是本体应用的数据生产管道。

当新的进水数据、设备状态、化验结果持续进入时，Ontology 世界也随之更新。

八、Ontology 有了以后，应用反而很简单

我们需要的是从 Ontology 中"抓"出你想要的数据，形成数据服务，这里一般用AI编程即可完成，因为本体结构有了、输出输出业务已知、过程算法承载在 OntoGraph 的标准API中。

围绕业务主线，应用可以收敛成几个核心分类：

应用分类	用户真正想问的问题	核心本体能力
运营驾驶舱	现在污水站怎么样？	Plant / ProcessState / Risk
工艺流向	风险沿什么路径传播？	ProcessUnit / PROCESS_FLOW
超标根因诊断	为什么超标？	Risk / Event / Cause
冲击事件	发生了什么？影响哪里？	Event / ProcessFlow
设备运维	哪台设备拖累工艺？	Equipment / Risk / ControlVariable
数据质量	哪些数据可信？	Sensor / Observation / LabTest
厌氧联锁	现在能不能进水？	Rule / ProcessState / Action

页面只是 Ontology 的一个"视图"。

真正的核心资产仍然是：

Ontology + Functions + Actions + Workflow

九、智能体不是重新做一套系统，而是调用本体能力

基于上述模型，可以定义出 5 个面向业务角色的 Skill：

Skill	业务角色	典型问题	调用的本体能力
值班班长	全站运营	现在怎么样？有没有超标？	overview / state / risk / event
工艺工程师	工艺分析	为什么超标？冲击怎么传？	root cause / flow / trend / risk
设备工程师	设备运维	哪台设备故障？影响什么？	equipment / impact / CV
厌氧联锁值班	安全控制	能不能进水？停在哪档？	interlock / control
仪表与化验	数据质量	在线数据可信吗？	data quality / lab comparison

例如用户问：

"1#曝气风机坏了，会影响什么？"

Skill 不需要自己"想象答案"，而是沿着本体（推理）：

text 复制代码

1#风机
 ↓ BELONGS_TO
A/O
 ↓ CONTROLS
A/O曝气能力
 ↓
DO
 ↓
生化处理能力
 ↓
出水风险

得到一个可解释的答案。

这就是：

AI 负责理解问题，本体负责提供真实业务世界。

十、用两批数据验证：本体必须经得起"变化"

本体应用不能只拿一批静态数据证明"能查"，而是用多批数据集来验证**"动态"本体**，到底哪里"动"了，这是可以在 OntoFlow 上运行观察出来的（直接跑工作流即可，也可以采用代码运行验证）。

本案例采用两批数据验证。

批次	工况	本体变化
demo：6/20	24h正常、出水COD<80、1#风机运行、厌氧正常	Plant进入 `NORMAL`，负荷从0开始累计
test：7/10	COD冲击至9000、1#风机FAULT、出水超标、化验偏差>30%、厌氧酸化	当前值由 `OrderedLast` 覆盖；负荷/药耗由 `Sum` 累加；事件/观测/化验形成新顶点
overlay	补充厌氧测点	仅更新AN_*数据，避免重复计算进水负荷
V2 overlay	状态、风险、CV、告警、测点定义	完成运行控制世界模型

最终得到的测试状态包括：

text 复制代码

厂站：RISK
进水 COD：5800
出水 COD：86
未闭环事件：7
故障设备：1
1#曝气风机：FAULT

厌氧：
STOP_REACTOR
pH：6.52 / 6.42
产气率：0.36
进水：0%
碱泵：开启
循环 E：320

这里尤其需要强调：

当前值和累计值必须区分。

例如：

OrderedLast：当前 COD、设备状态、pH 等；
Sum：周期负荷、药耗；
新顶点：事件、观测、化验、执行记录。

这样本体才真正具备"运行中的世界状态"。

十一、OntoX 孪生：不是把数据画出来，而是把世界看出来

OntoX 最适合承担：

"看见世界"，这是 Ontology 的其中一个价值体现

例如运营驾驶舱：

text 复制代码

污水处理厂
│
├── 进水：RISK
├── 调节池：WARNING
├── 厌氧：STOP_REACTOR
├── A/O：WARNING
├── 二沉：WATCH
├── 除磷：WATCH
└── 出水：CRITICAL

用户点击"1#曝气风机"：

text 复制代码

1#曝气风机
FAULT
   ↓
A/O曝气能力下降
   ↓
A/O风险
   ↓
出水风险

用户点击"出水 COD"：

text 复制代码

当前值
 ↓
时序
 ↓
相关事件
 ↓
进水冲击
 ↓
工艺影响
 ↓
设备影响

所以孪生页面展示的不是"更多图表"，而是：

对象 + 状态 + 关系 + 风险 + 建议。

且任意数据都可以进行智能问数 ，发现前因后果。

十二、OntoOS 推演：从"看见世界"到"改变世界"

孪生解决：

以前发生了什么？现在发生什么？

而 OntoOS 推演进一步解决：

如果我做什么，会发生什么？哪个方案更好？

第一阶段污水案例不强行做水质动力学预测，而采用状态级 What-if 推演。

例如：

场景一：切换备用风机

text 复制代码

当前：
1#风机 FAULT
A/O曝气风险 HIGH

        ↓
【切换2#备用风机】

        ↓

2#风机 RUNNING
曝气有效能力恢复
A/O曝气风险下降

但：

text 复制代码

出水 COD = 86

不会被凭空改成：

text 复制代码

出水 COD = 75

因为当前案例没有建立可信的 COD 动力学模型。

这恰恰体现了本体应用的严谨性：

能计算的就计算；没有模型支撑的未来数值不伪造。

十三、污水处理沙盘可以这样设计问题

推演问题不应该简单重复智能问数，而应该围绕：

"当前状态 → 行动 → 状态变化 → 方案比较"

来设计。

A. 态势认知

编号	推荐问题	预期回答
A1	当前污水厂状态、出水和故障情况怎么样？	Plant=RISK、出水超标、1#风机FAULT
A2	当前哪些工艺单元处于风险状态？	调节池、厌氧、A/O、出水等
A3	当前最大的运行风险有哪些？	冲击、曝气、出水、厌氧、数据漂移
A4	进水冲击如何沿工艺传播？	PROCESS_FLOW + Event影响链
A5	1#风机故障后曝气有效能力是多少？	CV-AO-AERATION≈0.22
A6	厌氧现在能不能进水？	不能，STOP_REACTOR
A7	在线COD还能作为控制依据吗？	偏差>30%，control_eligible=0

B. 策略推演

编号	推演问题	Action	观察结果
B1	如果切换2#备用风机，会发生什么？	`switchSpareBlower`	风机状态恢复、曝气风险下降
B2	如果只提高曝气量、不切风机呢？	`adjustAeration`	曝气设定提高，但FAULT仍存在
B3	启动应急调节池能否缓解进水冲击？	`startEqualization`	冲击风险下降
B4	按当前厌氧联锁执行，会发生什么？	`applyAnInterlock`	进水0%、碱泵开启、循环调整
B5	把COD仪表标为不可信后还能控制吗？	`markSensorUntrusted`	控制回路停止采信
B6	切风机后风险到底降低了多少？	查询 `ActionRecord`	对比动作前后状态

C. What-if / 方案比较

问题	沙盘应该回答什么
只切备用风机 vs 只提高曝气，哪个更合理？	前者能够消除设备故障影响，后者只是改变曝气设定
切风机后出水COD会不会马上降到80以下？	不会；当前模型只推演状态和风险，不伪造水质动力学
只处理风机故障，厂站能否恢复NORMAL？	不能；厌氧失稳、进水冲击等风险仍存在
如果什么都不做，当前风险主要会影响哪里？	沿 ProcessFlow 分析影响范围

这时，沙盘才真正和孪生形成区别：

text 复制代码

OntoX
看见世界
   ↓
智能问数
理解世界

OntoOS
改变世界
   ↓
What-if
比较世界

十四、最终形成一个完整的本体应用闭环

整个污水处理应用最终可以浓缩成一张图：

最终形成：

数据不是终点，数据进入 Ontology 后成为业务对象；对象形成状态，状态形成风险，风险驱动行动，行动改变世界，世界变化再次进入 Ontology。

十五、这个案例真正展示的不是"污水大屏"

如果只是传统方式，最终可能是：

text 复制代码

数据库
 ↓
BI
 ↓
图表
 ↓
AI问数

而 OntoFlow 的方式是：

text 复制代码

污水数据
 ↓
业务对象
 ↓
工艺关系
 ↓
运行状态
 ↓
风险
 ↓
控制变量
 ↓
Action
 ↓
执行结果
 ↓
Ontology World Model
 ↓
孪生监控 + AI Skill + 推演沙盘

两者最大的区别是：

传统系统管理"数据"；本体应用管理"数据背后的业务世界"。

在这个污水处理案例中，Ontology 最终认识的已经不是：

COD=5800、风机=FAULT、pH=6.52......

而是：

当前厂站存在进水冲击、A/O曝气能力不足、厌氧失稳和数据漂移等风险；1#风机故障正在影响A/O控制能力；厌氧联锁已经达到 STOP_REACTOR；某些在线数据不能作为控制依据；系统可以明确哪些 Action 能够改变哪些控制变量，并在动作后重新计算状态与风险。

这才是 OntoFlow 本体智能平台在污水处理厂中的真正价值。

一句话总结：如何自己构建一个 OntoFlow 本体应用？

以后面对任何行业数据，都可以套用这套方法：

① 看我有什么数据 → ② 定一个可闭环的小业务目标 → ③ 找出真正参与业务的对象 → ④ 用关系把对象组织成世界 → ⑤ 用函数把数据变成状态和风险 → ⑥ 用 ControlVariable 定义"什么可以被改变" → ⑦ 用 Action 定义"怎么改变" → ⑧ 用 OntoX 看世界 → ⑨ 用 OntoOS 推演改变后的世界。

不要从"我要做几个功能页面"开始。

应该从：

"这个业务世界里，谁在发生什么？为什么？我能改变什么？改变之后如何证明结果？"

开始。

这就是 OntoFlow 构建本体应用的核心方法。

OntoFlow 本体智能平台在污水处理厂的应用

基于 原生Ontology结构的 污水处理运营驾驶舱

一、先不要建本体：先回答三个问题

1. 分析我有什么？

二、分析我想做什么：先给业务定一个"小目标"

2.1 再确定一个可以真正闭环的业务场景

"进水冲击 → 工艺风险 → 设备影响 → 出水风险 → 控制动作"

三、把业务问题翻译成本体：不是"建表"，而是"建世界"

3.1 核心业务对象

3.2 最重要的不是对象，而是对象之间的关系

四、把"数据"变成"状态、风险和能力"

4.1 指标不要只是字段：建立 Metric + Observation

Metric（指标体系）

Observation（监控体系）

4.2 建立 ProcessState：回答"现在怎么样"

4.3 建立 Risk：回答"为什么值得关注"

五、让本体真正"会计算"：函数、派生与业务状态

① 负荷

② 冲击

③ 在线仪表偏差

④ 设备健康

⑤ 控制变量有效能力

六、Action 不是按钮，而是本体世界中的"改变"

七、把本体设计转成 OntoFlow 工作流

八、Ontology 有了以后，应用反而很简单

九、智能体不是重新做一套系统，而是调用本体能力

十、用两批数据验证：本体必须经得起"变化"

十一、OntoX 孪生：不是把数据画出来，而是把世界看出来

十二、OntoOS 推演：从"看见世界"到"改变世界"

场景一：切换备用风机

十三、污水处理沙盘可以这样设计问题

A. 态势认知

B. 策略推演

C. What-if / 方案比较

十四、最终形成一个完整的本体应用闭环

十五、这个案例真正展示的不是"污水大屏"

一句话总结：如何自己构建一个 OntoFlow 本体应用？

基于原生Ontology结构的污水处理运营驾驶舱

`Metric（指标体系）`

`Observation（监控体系）`