干化工过程故障检测这行最怕的不是仪表坏了而是仪表没坏、系统也告诉你一切正常结果装置就在你眼前一点点跑偏等DCS报警响起来的时候已经晚了。我在现场吃过这种亏所以后来转到数据驱动这条路上越做越觉得这条思路在化工这种高耦合、大滞后的场景里有它独到的价值。坦白说化工过程故障检测并不是一个新话题。从最早的3σ阈值报警到基于机理模型的解析冗余再到今天的机器学习、深度学习整个行业始终在跟一个核心问题较劲如何在故障发生的早期甚至是在故障特征还淹没在噪声里的阶段就把它可靠地识别出来。本文从实际项目的角度把数据驱动化工过程故障检测这条路完整梳理一遍——从数据从哪来、用什么算法、特征怎么选到代码怎么写、部署时有哪些坑尽量讲透附上可以直接跑的Python代码给正在做类似工作的同行一个参考。适合刚入门的过程系统工程研究生、转行做算法工程化的开发者以及想在工厂里落地数据建模的工艺工程师。1. 化工过程故障检测从“阈值报警”到“数据驱动”的必然转向1.1 传统DCS报警架构为什么越来越不够用化工装置的DCS报警系统本质上是基于单变量的阈值判断。温度高了就报温度高液位低了就报液位低每个测点独立工作互不商量。这套逻辑在过去装置规模小、流程相对简单的时候是够用的但放到现在一套大型化工装置动辄上千个测点变量之间强耦合、强非线性单变量报警的短板就暴露得很明显。我举一个很典型的例子精馏塔的塔釜液位和塔底温度这两个变量本身就存在强关联。液位偏高时塔底再沸器的传热面积会变化塔底温度会跟着波动温度波动又会影响塔顶组分塔顶压力也跟着动。如果是单变量阈值报警可能压力报警先响了操作员盯着压力去调结果越调越乱。这时候数据驱动的方法怎么看这个问题它会把温度、液位、压力、流量甚至阀门开度几十个变量放一起得到它们之间的联合分布关系。故障的早期特征往往是这种联合关系被打破而单看任何一个变量都还在“正常范围”内。1.2 数据驱动方法到底在解决什么问题一句话概括数据驱动故障检测做的是“找异常”而不是“找原因”。它先通过正常工况的历史数据建立一套“正常行为”的参考系然后对实时数据进行检验如果实时数据明显偏离这个参考系就判定为异常状态。这里要注意一个区别异常检测不等于故障诊断。检测是在回答“系统现在是不是出问题了”诊断是在回答“具体是哪个部件、哪种原因出的问题”。很多初学者一上来就想做诊断实际上连稳定的检测都还没做到。工业现场的真实需求里先把“检测”做牢能及时报警并避免跳车就已经有了很大的安全价值诊断可以放在第二步靠分类模型或知识图谱逐步推进。1.3 哪些场景最适合先用数据驱动方案如果你所在的企业也想推进这件事我建议不要追求一步到位。优先级最高的一定是这么几类场景关键机组压缩机、泵的在线监测这类设备测点齐全、历史数据保存完整故障样本虽然少但机理相对清晰。间歇过程或批次过程的质量门限控制批次数据的重复性天然适合统计建模。连续过程的关键质量指标软测量与趋势预警当质量指标无法实时测量时通过过程变量预测质量趋势。已有报警泛滥的装置很多时候报警太多操作员已经麻木了用数据驱动做报警管理能大幅减少无效报警。这些场景的共同点是数据基础好、业务边界清晰、出了问题影响大。先在这类场景里跑通再考虑扩大范围。2. TE过程数据集所有化工故障检测研究的“普通话”2.1 TE过程是什么为什么它绕不开做化工过程故障检测和监控有个数据集你早晚要遇到——TE过程Tennessee Eastman Process。这个仿真过程是由美国Eastman化学公司的研究人员提出的最初是用来评价过程控制和监控方法的一个基准平台。我个人的感受是如果你跟做化工过程系统工程的人聊故障检测TE过程基本上就是“普通话”大家用它来对齐语言、比对结果谁都绕不开。TE过程本身模拟的是某化工装置的真实工艺包含5个主要操作单元反应器、冷凝器、气液分离器、汽提塔和循环压缩机。整个流程涉及4种气体进料、2种产物、1种副产物还有惰性组分和可选的进料成分。反应器里发生的是不可逆放热反应所以温度控制非常关键。这套工艺的逻辑跟我们熟悉的化工流程高度一致这也是它被广泛接受的根本原因。2.2 数据集的21种故障是怎么设计的TE数据集最大的价值在于它提供了21种预定义的故障场景每条场景都有训练集和测试集。这些故障按类型可分为几类阶跃类故障Step比如进料组分突变、反应器冷却水温度突变模拟过程中断然发生的扰动。慢漂移类故障Drift比如进料温度缓慢变化模拟催化剂失活、结垢这类渐进式劣化。阀粘连类故障Sticking比如循环阀卡在某个位置模拟执行机构失效。其他类型包括反应动力学参数变化、未知扰动等。每种故障的测试集都是从故障引入的时刻开始记录的。比如某个故障在第160个采样点引入那么前160个点就是正常工况后面就是故障工况。这个结构和工业现场的“系统前一天还正常今天开始出问题”几乎一模一样所以非常适合用来验证检测算法的预警能力。我建议刚接触TE过程的读者把注意力重点放在故障1、故障2、故障4、故障6、故障7、故障8、故障12、故障13、故障14这几类上。它们相对经典前人结果多适合做对比而故障3、故障9、故障15属于出了名难检的很多高级算法也搞不定不建议作为入门第一关。2.3 数据导入与基础预处理TE数据集的官方形式是MATLAB的.mat文件网上的常见版本里每个文件都包含了52个观测变量——41个过程变量加11个操作变量。采样间隔通常是3分钟对应一个批次480个采样点故障在161个点处引入。使用Python做实验时一般用scipy.io的loadmat来读取.mat文件之后转成DataFrame。这里顺手给一段读取代码import scipy.io import pandas as pd import numpy as np def load_te_data(file_path): 读取TE数据集的.mat文件 返回DataFrame列名为XMEAS_1..XMEAS_41, XMV_1..XMV_11 mat scipy.io.loadmat(file_path) # TE数据集常见字段是 X形状为 (n_samples, 52) data mat[X] columns [fXMEAS_{i} for i in range(1, 42)] [fXMV_{i} for i in range(1, 12)] df pd.DataFrame(data, columnscolumns) return df # 用法示例 # df_train_normal load_te_data(d00.dat.mat) # 正常工况训练数据 # df_test_fault1 load_te_data(d01_te.dat.mat) # 故障1测试数据拿到数据之后第一步做标准化。所有数据驱动方法的前提假设都是变量在同一尺度下比较才有意义温度的量纲是摄氏度流量的量纲是立方米每小时不标准化的话PCA会天然偏向数值大的变量。这里建议用训练集的均值和标准差来标准化测试集不能把测试集的标准差混进来算否则就是信息泄漏。3. PCA故障检测经典方案的原理和它的边界3.1 主成分分析在这里到底扮演什么角色PCA主成分分析在故障检测里做的事情用一句话说就是降维不丢主信息。化工过程几十上百个过程变量彼此强相关实际起作用的自由度远小于变量个数。PCA找到一组新的正交方向让数据在这几个方向上的方差最大这些方向就是主成分。选前k个主成分就能用k维空间近似表达原来的高维数据。为什么这对故障检测有帮助因为正常工况下变量之间的相关关系是稳定且有规律的数据点会落在一个低维流形附近。当故障发生时这种相关关系被打破数据点就会偏离原来的流形。这种偏离通过统计量可以直接定量判断。3.2 T²统计量与SPE统计量到底在检测什么PCA故障检测通常用两个统计量第一个是Hotelling的T²统计量它度量的是样本在主成分空间里的位置到原点的距离。T²大说明你在主成分方向上的偏离大。从物理意义上讲它捕捉的是“方差过大”的那种异常比如某个关键变量虽然还在正常范围但若干个变量的组合幅度异常了。第二个是SPE统计量也称Q统计量度量的是样本在残差子空间里的投影长度。PCA降维之后原始数据点不会完全落在主成分子空间上它和投影点之间的距离就是残差。SPE大说明出现了主成分模型没有捕捉到的新模式。这往往对应“变量相关关系被打破”这类故障对化工场景尤其重要。两个统计量一个看主空间、一个看残差空间实际上互为补充。正常工况下T²和SPE都在控制限内均值漂移类故障往往T²先超限传感器故障或变量关系突变SPE的反应更灵敏。真正落地的时候两个统计量要同时监控任何一个超限都算异常不能只盯着一个。对于控制限的确定T²理论上可以用F分布近似得到SPE常用其近似分布或直接用训练数据的经验分位数。工程上我更推荐用训练数据的分位数因为在真实数据上严格的理论分布假设往往不完全成立。3.3 为什么PCA在连续化工过程中会露怯PCA好用、直观、可解释性强但它有一个致命的前提假设采样点之间相互独立。化工过程是典型的动态系统前一时刻的状态会传导到后一时刻采样间隔3分钟的数据点之间并不独立存在严重的自相关。在这种情况下PCA提取的主成分实际上是“静态”的它忽略了时间维度上的动态信息。这会导致什么问题一个缓慢漂移的故障比如某个设备慢慢结垢每个时刻看都不算异常但时间上看就是连续缓慢偏离正常轨迹。静态PCA对这种渐变非常迟钝等它报警的时候故障可能已经发展了好几个小时。另外过程本身的正常波动也会被PCA视为“偏移”导致误报率偏高。理解了这一点就明白为什么在TE数据集上纯PCA的检测率看似还行但把误报率拉出来看往往不够理想。要解决动态问题思路是让模型“记住”时间——这就引出了DPCA、CVA这类动态方法以及目前在工业界越来越常见的自编码器方案。4. 进阶思路动态性、非线性与多模态问题4.1 DPCA与CVA怎么把时间维度塞进模型既然PCA忽略了时间相关性最简单的改进就是把每个变量的历史时刻也当成新变量一起放进PCA里——这就是DPCADynamic PCA的基本想法。比如把当前时刻和过去两个时刻的变量拼接成一个扩展向量相当于每个变量多带了两步“记忆”PCA就能捕捉到一部分时间动态。在TE数据上DPCA对慢漂移类故障的检测效果往往明显优于静态PCA这个提升非常直观。但DPCA也有些粗糙扩展窗口到底取几拍需要反复试对非线性动态的建模能力仍然有限。比DPCA更严谨的做法是CVACanonical Variate Analysis典型变量分析它把过去时刻的变量集和未来时刻的变量集做典型相关分析找到最能预测未来的状态方向。CVA在化工过程监控里表现公认不错只是计算复杂度高一些参数调起来更麻烦。4.2 KPCA和自编码器非线性问题怎么破化工过程本质上是非线性的反应速率跟温度之间就是典型的阿伦尼乌斯关系标准的线性PCA在这种数据上天然吃亏。KPCA核主成分分析通过核技巧把数据映射到高维空间后再做PCA相当于在高维空间里捕捉非线性结构在TE数据上对某些非线性故障确实有明显的提升。但KPCA有个工程上的硬伤在线应用时计算量大。因为它的每个新样本都要和所有训练样本计算核函数数据量一大速度就慢。而且模型的可解释性也变差了你很难说清楚某个主成分到底对应什么物理含义。自编码器是另一种思路。它先用编码器把高维输入压缩到低维隐变量再用解码器重构输入。如果模型只在正常数据上训练那么正常样本的重构误差会很小一旦来了故障样本模型没见过这种模式重构误差就会显著变大。这个思路非常直观在工业界落地的也越来越多。相比PCA自编码器天然支持非线性相比KPCA它的在线推理速度快得多训练好以后就是一个前向计算。4.3 故障分类与状态识别检测之上的下一步检测解决了“是不是出问题”紧接着的问题就是“出了哪类问题”。在TE数据上很多研究把它当21分类问题做但实际上标准的分类模型在这里很容易翻车原因是这21类故障之间严重不平衡有些故障样本极少而类与类之间还有相似性。在工程上我建议换个思路不要一口气做21分类而是把故障类型按系统部位或故障性质分组。比如冷却水故障归一组、进料组分故障归一组、阀门故障归一组先做第一层的粗分类再在组内做细分类类似于决策树的层级结构。这种层级分类在工业现场的可操作性远远好于一个大而全的21分类模型。5. 一整套可运行的故障检测代码拆解5.1 代码概览与核心思路这一节给出可直接运行的PCA故障检测代码包括模型训练、阈值计算、在线检测三个部分。考虑到TE数据集下载对部分读者有门槛代码里也会留出合成数据的通道方便先把流程跑通再套真实数据。整体流程如下加载正常工况训练数据标准化。在正常数据上拟合PCA。用训练数据计算T²和SPE统计量取99%分位数作为报警阈值。加载故障测试数据用训练集的均值和方差做同样的标准化。对逐样本计算T²和SPE与阈值比较得到报警信号。统计检测延迟和误报率。完整的思路是先离线把“正常是什么样”学好再在线判断“当前是不是偏离了正常”。5.2 主代码训练阶段import numpy as np import pandas as pd from sklearn.preprocessing import StandardScaler from sklearn.decomposition import PCA def train_pca_model(df_normal, n_componentsNone, variance_ratio0.75, alpha0.99): 输入正常工况DataFrame 输出scaler, pca, 阈值 X df_normal.values # 1. 标准化 scaler StandardScaler() X_scaled scaler.fit_transform(X) # 2. PCA降维 if n_components is None: # 方差贡献率达到75%所需的主成分个数 pca_temp PCA() pca_temp.fit(X_scaled) cumsum np.cumsum(pca_temp.explained_variance_ratio_) n_components np.where(cumsum variance_ratio)[0][0] 1 pca PCA(n_componentsn_components) T_train pca.fit_transform(X_scaled) # 主成分得分 X_recon pca.inverse_transform(T_train) E X_scaled - X_recon # 残差 # 3. 计算统计量 T2_train np.sum((T_train / pca.explained_variance_) ** 2, axis1) SPE_train np.sum(E ** 2, axis1) # 4. 阈值取经验分位数 T2_limit np.quantile(T2_train, alpha) SPE_limit np.quantile(SPE_train, alpha) return scaler, pca, T2_limit, SPE_limit有一点说明代码里T²的计算方式用的是“每个主成分除以对应特征值后平方和”这在数值上等价于马氏距离。有的资料里会写成T² T Λ⁻¹ T.T逻辑一样。5.3 主代码在线检测阶段def online_detection(df_test, scaler, pca, T2_limit, SPE_limit): 输入测试数据流按行逐样本 输出T2序列、SPE序列、报警布尔序列 X_test df_test.values X_scaled scaler.transform(X_test) T2_seq [] SPE_seq [] for x in X_scaled: x x.reshape(1, -1) t pca.transform(x)[0] x_recon pca.inverse_transform(t.reshape(1, -1)) e x - x_recon T2 np.sum((t / pca.explained_variance_) ** 2) SPE np.sum(e ** 2) T2_seq.append(T2) SPE_seq.append(SPE) T2_seq np.array(T2_seq) SPE_seq np.array(SPE_seq) alarm_T2 T2_seq T2_limit alarm_SPE SPE_seq SPE_limit # 综合报警任一统计量超限即报警 alarm np.logical_or(alarm_T2, alarm_SPE) return T2_seq, SPE_seq, alarm在线检测的循环方式可能看着笨但更接近真实系统的使用方式——真实系统就是一个样本一个样本往模型里送。如果追求效率也可以用向量化计算这里为了教学保留循环结构。5.4 如何计算检测延迟和误报率检测延迟是故障检测里最关键的指标之一。TE数据集的每个故障测试文件里都注明故障引入的采样点多数是第161个点。检测延迟的计算方式很直接从第161个点开始找到第一个报警点两者的差值就是检测延迟。def evaluate_detection(alarm, fault_start_idx160, warmup_idx100): 计算检测延迟与误报率 fault_start_idx: 故障引入下标TE数据集通常为160即第161个点 warmup_idx: 前100个点作为稳定期不计入误报统计 # 误报率故障引入前被误报为故障的比例 false_alarm_ratio np.mean(alarm[warmup_idx:fault_start_idx]) # 检测延迟故障引入后首次报警点与故障引入点的距离 alarm_after np.where(alarm[fault_start_idx:])[0] if len(alarm_after) 0: detection_delay None else: detection_delay alarm_after[0] return false_alarm_ratio, detection_delay # 示例调用 # fpr, delay evaluate_detection(alarm) # print(f误报率: {fpr:.3f}, 检测延迟: {delay} 个采样点)误报率这里其实也有讲究。严格意义上误报应该是在“系统正常”的阶段报警。TE测试集在故障引入之前的那段时间可以认为是正常阶段所以用它来统计误报。前100个点很多时候是系统初始波动阶段模型报警会比较频繁这部分要单独看不应该和稳态误报混在一起。5.5 用合成数据快速验证代码流程TE数据如果暂时拿不到可以先造一组带相关结构的三变量数据来验证流程。这个方法在调试代码时特别顺手可以让你快速确认自己的代码链路没有断再换成真实数据。def generate_synthetic_data(n_normal500, n_fault200): 合成数据 正常段三个变量两两相关高斯噪声 故障段变量之间的相关系数被破坏 np.random.seed(42) # 正常段 cov np.array([[1.0, 0.8, 0.5], [0.8, 1.0, 0.6], [0.5, 0.6, 1.0]]) X_normal np.random.multivariate_normal(mean[0, 0, 0], covcov, sizen_normal) # 故障段 cov_fault np.array([[1.0, 0.1, 0.1], [0.1, 1.0, 0.1], [0.1, 0.1, 1.0]]) X_fault np.random.multivariate_normal(mean[0, 0, 0], covcov_fault, sizen_fault) df_train pd.DataFrame(X_normal, columns[V1, V2, V3]) df_test pd.DataFrame(np.vstack([X_normal[:100], X_fault]), columns[V1, V2, V3]) return df_train, df_test # 验证流程 # df_train, df_test generate_synthetic_data() # scaler, pca, t2_lim, spe_lim train_pca_model(df_train) # t2, spe, alarm online_detection(df_test, scaler, pca, t2_lim, spe_lim)这个合成数据的思路是把故障模拟成“相关结构被打破”恰好是PCA模型最擅长捕捉的异常模式。跑一遍之后你应该能在故障引入的位置看到报警密集出现这个过程很容易直观理解。5.6 从仿真到工业数据的改造要点用TE数据跑通模型之后切换到工业现场的DCS历史数据有几个地方必须调整数据清洗DCS历史数据里包含大量停开车阶段、仪表检修置零、通讯中断产生的缺失值这些数据不能直接喂给模型。建议先剔除非稳态工况段再对缺失值做插补或删除。数据压缩DCS存储的数据经常是秒级甚至毫秒级而TE数据是3分钟一个点。工业建模一般要重采样到分钟级或按工艺需要聚合否则计算量大而且秒级噪声会掩盖真实趋势。工况分段一套装置可能有多套工艺运行方案、多个负荷段。不同工况下变量关系不一样建议先按工况分段分别训练模型或者用多模态建模方法处理。6. 数据驱动故障检测落地时最容易被低估的五个细节6.1 数据质量比模型选择更致命在TE数据集上调参调来调去检测率也就差几个点。但在工业现场数据质量差再好的模型也是白搭。最常见的问题是数据标签不可靠。历史数据里的“正常”和“故障”标签是怎么来的如果是靠人工翻阅DCS历史标注的那么大概率有大量错标和漏标。我见过一个项目用历史数据训练故障分类模型现场工程师拍胸脯保证标签正确结果模型上线后一查所谓“故障”样本里有三分之一是正常工况的负荷调整段。这会让模型学习到完全错误的模式。另外DCS数据的采样和对齐也需要注意。不同测点的采样频率可能不同有的每秒采有的每分钟采直接拼在一起会造成变量之间的伪相关。建议统一重采样后再建模型。6.2 工况切换与概念漂移会悄悄毁掉模型化工装置不会永远停在同一个负荷。催化剂活性会下降换热器会结垢原料组分会有波动这些都会让过程变量之间的关系发生缓慢但持续的变化。模型在三个月前训练时的“正常范围”到今天可能已经不适用了——这个过程叫概念漂移。处理漂移的思路有两个方向一是定期用近期正常数据重新训练模型这是最简单实用、也是工程中最重要的做法二是用自适应模型让模型在线更新但这在工业场景里风险较高容易把真实的故障也“自适应”掉。我的建议是起步阶段先做定期重训比如每周或每月用最新的正常工况数据重新拟合一次PCA同时把旧模型保留对比一下新模型和旧模型的报警差异能看出数据是否发生了明显漂移。6.3 故障样本不足时如何自救真实的工业场景里“正常”数据好找“故障”数据极其稀缺。一套装置一年下来可能就出过两三次故障而且每次故障的情况还不一样。这种情况下想直接训练一个有监督的故障分类模型几乎不可能。对策有这么几个异常检测优先于故障分类只在正常数据上训练模型通过偏离度来判断异常。这个思路和本文讲的方法一致非常适合故障数据稀缺的场景。利用仿真数据弥补如果装置有成熟的机理仿真模型可以通过仿真生成各种故障工况的数据用来预训练模型再用真实数据进行微调。相似装置数据迁移集团内部多个同类装置把A装置上积累的故障数据用来辅助B装置的建模。6.4 误报率和漏报率之间怎么权衡实际部署时模型调参不可能让误报和漏报同时为零。这里有个工程上的取舍问题误报太多操作员会关掉报警漏报一次可能就是一次非计划停车甚至安全事故。正确做法是跟现场工艺工程师、安全管理人员一起定阈值而不是算法工程师自己拍脑袋。你可以给出一组不同阈值下的误报率、漏报率、检测延迟曲线让业务方来选择可接受的操作点。很多时候现场宁可接受稍高一点的误报率也要保证故障出来时的检测速度。还有一种做法是设置两级报警黄灯预警和红灯报警黄灯阈值宽松一些红灯阈值严格一些这样既减少操作员负担又保证关键故障不丢。6.5 模型的解释性现场工程师需要知道“为什么”数据驱动模型上线后现场工程师问的第一个问题往往是“它凭什么报警”如果模型给不出任何理由哪怕准确率再高也很难被信任。PCA在这方面的表现相对友好。当T²超限时可以计算每个变量对T²的贡献率找出贡献最大的几个变量作为“嫌疑变量”SPE超限时同样可以看残差中哪个变量的贡献最大。这样至少能告诉现场工程师问题可能出在哪几个测点附近。自编码器和深度学习模型在这个问题上就比较吃亏通常需要额外的归因方法比如SHAP值或梯度归因但这些方法在在线场景下计算开销不小。7. 模型上线后还需要做哪些事模型开发出来只是第一步真正考验人的是上线后的持续运行。我建议新上线的模型至少要有三个月的观察期期间每天对比模型报警和实际工况。每个报警都要记录是真警、误报还是漏报这个反馈闭环决定了后续模型优化的方向。在实际项目里我习惯把模型报警和DCS操作记录放在同一个看板上。操作员做了什么调整什么时候调的模型在什么时候报警对照起来看非常有助于理解模型的行为逻辑。很多模型误报追根溯源都和处理模型设计的误区有关——比如没有把停留时间、纯滞后等工艺特性考虑进去导致报警永远比真实故障慢半拍或者把正常的负荷调节误判成故障。这些反馈和沉淀比模型本身的算法更重要。最后还有一个小建议如果你准备在自己的团队里推进这件事先从一条工艺线的一个关键设备做起不要求大求全。把一条线做透了从数据、模型到界面、运维形成一套可复用的流程再横向推广。数据驱动故障检测这个方向的坑多到一篇说不完但每一个踩过的坑最后都会变成更可靠的模型和更成熟的方法论。