一、背景

抽油机井的工况诊断，长期以来靠人，技术人员一张一张看，判断这口井是否正常。xx油田有十万多口油气水井，分布在陕甘宁蒙交界的大片区域，靠人力覆盖这个体量，难度可想而知。

更麻烦的是时间差。皮带断了、蜡卡了，从发生到造成实质影响，可能就几十分钟。等示功图传回中心、排队处理、人工分析完，往往已经晚了。供液不足、游动阀漏失这类隐性故障更隐蔽，产量不会立刻掉，但泵效一天天往下走，等发现时已经积累了不少损失。

XT916这款井口控制器，做的事情就是把诊断能力从中心搬到井口。数据在哪产生，就在哪算完。

二、架构思路

传统功图监测系统的数据流向是：传感器→RTU→通信链路→中心服务器→人工分析。这个链条里，通信和算力都集中在后端，前端只负责采集和上传。

XT916换了个做法。它在控制器内部直接跑一个训练好的1D-CNN模型，示功图采集完就地推理，诊断结果作为轻量信息上传，原始曲线存在本地SQLite数据库里备查。中心服务器收到的不是原始数据，而是已经分类好的工况标签。

这样做的直接好处有两个。一是快，故障从发生到告警的时间从小时级压到冲程级；二是省，原始示功图数据量很大，一个采油厂每天产生的数据点以千万计，全部上传对带宽和服务器都是持续压力，现在这部分流量被砍掉了。

偏远井场通信条件不好的时候，这个架构的优势更明显。4G断了，井口端的诊断还在跑，告警可以通过Zigbee在井场局域网内传，等链路恢复了再同步。

三、硬件与接口

XT916的硬件配置不算高，Cortex A7处理器，1GHz主频，128M DDR3内存，8G工业级FLASH，跑嵌入式Linux。这个算力放在通用计算领域很普通，但跑一个已经训练好的推理模型够用了。

接口方面，8路DI、6路继电器（其中2路带常开常闭触点）、8路AI，可以直接接现场传感器和执行机构。串口有8个，4路可编程做主站，2路专门接两种不同的Zigbee模块，1路保留做Linux终端。这种多串口冗余设计在通用PLC里不常见，但油田井场确实需要同时对接载荷传感器、电参数模块、无线网关和调试终端。

通信上，2个以太网口可以分别设不同地址，内置WiFi可做AP或网络接口，4G是可选模块。Zigbee接口明确支持长庆油田通信协议和A11协议标准，这一点比较关键——A11是中石油的企业标准，支持它意味着XT916不需要额外的协议转换网关就能接进长庆油田已有的数字化系统。对于已经部署了几万口井的成熟油田，兼容现有基础设施比技术先进更重要。

四、诊断模型的能力和局限

XT916用的是1D-CNN，不是2D-CNN。这个选择有讲究。示功图的本质是一维时序信号——载荷随位移变化，不是二维图像。传统方法常把它渲染成图像再用2D-CNN处理，但渲染过程本身会丢信息，也算得多余。1D-CNN直接在一维信号上做卷积，更贴合数据原始形态，推理也快。

可识别的工况包括：正常工作、供液不足、伴气影响、气锁、碰泵、阀关闭延迟、柱塞脱出、游动阀漏失、固定阀漏失、皮带断、皮带打滑等。其中“伴气影响”和“阀关闭延迟”这两类值得注意，它们不表现为载荷突变，而是曲线细微形变，传统阈值报警抓不到，CNN的特征提取能力在这上面有优势。

但模型也有边界。XT916用的是预训练参数，诊断能力受训练数据覆盖范围限制。长庆油田是“三低”油藏——低渗透、低丰度、低产出，供液不足是高频工况，而不同井的供液不足示功图特征又有细微差异，取决于井深、杆柱组合、泵径、冲程冲次。一套通用模型能不能在长庆的特殊工况下保持准确率，需要实际运行数据来验证。

学术研究方面，中国石油大学（北京）和长庆油田合作的一项工作表明，结合多尺度归一化的ResNet-18在示功图分类上能做到95.6%的整体准确率和92.8%的复杂工况召回率。这个数据说明深度学习用于示功图识别已经过了可用门槛。但研究也指出，误报警的一个主要来源是以单张地面示功图作基准，需要采用3σ准则剔除异常后叠合处理，并建立动态更新机制。XT916的本地诊断怎么和这类基准管理策略配合，是现场调优要解决的问题。

五、部署中要面对的事

控制器本身的参数只是一个起点，真正决定效果的是部署之后的运维。

模型适应性问题。 预训练模型到一个新油田，准确率会打折扣，这几乎是一定的。解决办法只能是持续积累现场数据，逐步微调。XT916内置WEB服务器支持网页升级，单台设备更新不难，但几千台分布在不同井场的控制器怎么批量管理，需要配套的远程运维工具。

误报和漏报的平衡。 系统自动推“皮带断脱”告警，现场得多快响应？误报多了，告警很快没人看；漏报多了，部署就失去意义。这个平衡点需要在运行中慢慢找。

传感器和物理因素。 示功图诊断的误差不全是模型的问题。载荷传感器安装状态、载荷漂移、结蜡导致的曲线畸变，都会影响输入数据质量。边缘计算解决的是算力位置问题，解决不了传感器可靠性问题。

六、小结

XT916的思路不复杂：把诊断从中心搬到井口，让数据在产生的地方就产生价值。对于正在做数字化转型的油田，这个方向值得关注。它的意义不只是替代人工巡井，而是为每口井建立连续的工况记录——只有数据被实时记下来、分析掉，才有可能从“出了故障再处理”变成“故障还没成形就发现”。

当然，边缘智能落地从来不是算力堆上去就行。传感器、通信、模型、运维，哪个环节掉链子都不行。XT916的参数给了一个可用的起点，但最终能不能在几万口井上站住，靠的是参数之外的东西：现场经验的积累、模型的持续迭代，以及运维体系跟不跟得上。