ITPub博客

做数据采集的人都知道一句话：“Garbage in, garbage out.” 数据质量不行，后面做什么分析、什么AI、什么优化，全是白搭。一个让我印象深刻的数据质量事故。一个化工厂的反应釜温度监测项目。反应釜里有强放热反应，温度必须控制在150±5℃。超过160℃就要紧急冷却，超过170℃就要紧急泄压。系统上线三个月，一直没有问题。温度稳定在150℃左右。然后有一天，温度突然从150℃涨到了1

为什么做这个测试？ 上篇聊了纯Python SIP协议栈的实现，评论区最集中的质疑是：Python做信令，性能能跟C库比吗？我做了一组对比测试。测试对象：PyGBSentry：纯Python实现的SIP协议栈PJSIP：业界广泛使用的C语言SIP协议栈Sofia-SIP：另一款主流C语言SIP协议栈测试环境：8核16G云服务器，Ubuntu 22.04，Docker部署。测试项目 测试1：单条SI

JT808 协议里关于分包的定义，只有短短几句话：当消息体属性中的长度大于 1024 字节时，终端应分包发送。分包消息的消息体前 4 字节为消息包总数和包序号。标准没说清楚的事太多了。问题一：分包大小是多少？标准说“大于 1024 字节时分包”，但没说分包的单位是多少。我一开始以为是按 1024 字节分包，后来发现不同终端厂商的实现不一样。有的按 1024 字节，有的按 512 字节，有的按 25

OPC UA是工业通讯的未来——这句话我信。但OPC UA的“信息模型”这个事，我踩了两年坑才搞明白。先说一个让我头疼的项目。一个水处理厂的项目，要上一套OPC UA服务器，把全厂的设备数据统一暴露给上层系统（MES、SCADA、云端）。设备有：6台PLC（西门子、三菱、汇川都有）、12台仪表（流量计、pH计、浊度仪）、4台变频器、2台软启动器。我搭了一个OPC UA服务器，把所有的数据点都配了上

摘要 GB28181 接入是链式流程：注册→保活→目录→点播→媒体流。任何一环断裂，后面都无法进行。GBDoctor 用分段推进引擎，自动定位断点。本文解析其状态机设计与实现。链式依赖注册成功 → 才能发保活    保活稳定 → 才能查目录    目录完整 → 才能点播    点播成功 → 才能收 RTP    如果注

一、一个反直觉的数据 数据库迁移中，DML 查询的自动转换成功率接近 100%。但存储过程、函数、触发器等过程性对象的自动转换成功率，规则引擎只能做到 3.8% 到 31.2%-1。同一个工具，同样的语法解析引擎，为什么差距这么大？二、语法树能解析的，和业务逻辑能理解的，是两回事 存储过程的核心问题在于：它不只是语法，它是业务逻辑的容器。一个 500 行的 PL/SQL 存储过程里，可能包含：嵌套

背景 做国标GB28181项目，最让人头疼的不是协议本身，而是各家设备的“方言”。协议文档写得清清楚楚，但到了实际对接，海康、大华、宇视各有各的实现方式。同一套平台代码，海康能注册，大华注册不上；大华能点播，宇视点播黑屏。我前后对接过几十款设备，踩了不少坑，今天把常见的兼容性问题整理出来，附排查方法和调试技巧。坑1：海康设备注册不上——网关配置的隐藏陷阱 场景：一台海康IPC，GB28181配置反

这两年工业AI很火。预测性维护、质量检测、能耗优化——每个方向都有公司在做。但真正落地的项目，不到10%。剩下的90%死在什么地方？死在数据上。一个真实的预测性维护项目，做了半年，失败了。客户是一个注塑厂，想用AI做注塑机的预测性维护——通过分析注塑机的压力、温度、速度曲线，预测模具什么时候会出问题。想法很好。注塑机的PLC里有完整的工艺参数——注射压力、保压压力、熔胶温度、模具温度、注射速度、保

JT808协议里有一条规则，写在标准文档最不起眼的位置：消息体中如果出现0x7e，需要转义为0x7d 0x02；出现0x7d，转义为0x7d 0x01。看起来很简单。我第一次实现的时候，也是这么想的。Bug是怎么出现的去年做一个运输车辆平台，JT808解析跑了一段时间都正常。直到接了某厂商的一批终端，问题来了：大约5%的位置上报消息解析失败，校验码不匹配。抓包看原始数据，帧头和帧尾的0x7e都在，

摘要 GB28181 故障模式繁多，厂商实现各异。GBDoctor 用 YAML 声明式规则库，将诊断知识从代码中解耦，支持社区贡献与持续沉淀。本文解析规则引擎的设计与实现。为什么需要规则库如果每个故障都写死在 Go 代码里：新增规则要改代码、重新编译社区无法贡献厂商差异难以维护规则库的目标：让诊断知识可积累、可版本化、可社区化。规则结构一条规则包含：ruleid: REG-401-ALGO ca

为什么选择 Go + Wails DBBridge 的技术栈是 Go（后端）+ Vue 3（前端）+ Wails（桌面框架）。这个选择背后有几个关键考量：零依赖分发的需求用户下载一个数据库迁移工具，不应该需要先安装 JDK、Python 或任何运行时。Go 编译出的静态链接二进制文件天然满足这个需求。纯 Go SQLite 驱动大多数 Go 项目的 SQLite 驱动（如 mattn/go-sql

网络抖动是视频播放最大的敌人 做安防视频项目的都知道，实验室里跑得好好的，到了客户现场就出问题。为什么？网络环境不一样。实验室是千兆交换机，客户现场可能是4G、WiFi、工业环网，丢包、抖动、带宽波动，什么都有。GB28181默认走UDP。UDP的特点是无连接、不保证顺序、不保证到达。网络一抖动，画面就花屏、卡顿、甚至断流。PyGBSentry做了三层播放自愈机制：RTCP NACK、UDP降级T

最近三年，制造业数字化转型的项目里，“OT/IT融合”是被提得最多的词。IT部门想把工厂数据接入MES、ERP、云端；OT部门担心安全问题，怕生产网络被外部攻击。这个矛盾，我见过太多项目卡在这里。一个真实的项目，卡了8个月。客户是一个汽车零部件厂，IT部门想采集产线上30台设备的数据到MES系统。OT部门（设备科）坚决反对——理由是“生产网络不能跟办公网连通，万一被攻击了，整条产线停摆”。IT部门

GBDoctor 是一个 GB/T 28181 接入诊断工具，采用纯 Go 实现，零 CGO 依赖，单二进制交付。本文从整体架构、SIP 协议栈、诊断引擎、规则库、报告生成五个层面，拆解其工程实现。为什么选择纯 GoGB28181 诊断工具需要跑在集成商现场：Windows 笔记本、Linux 服务器、甚至 ARM 网关。传统方案依赖 Python + libpcap + Wireshark，部署

一、为什么类型映射是异构迁移最难的部分数据库迁移工具看起来简单——读数据、写数据。但真正做过异构迁移的人都知道，最复杂的不是数据传输本身，而是 SQL 方言转换和数据类型映射。Oracle 的 NUMBER 精度与 MySQL 的 DECIMAL 存在微小差异，在金融计算场景中可能导致舍入误差；SQL Server 的 DATETIME 与 PostgreSQL 的 TIMESTAMP 在时区处理

2026年，SRE领域正在经历一次范式转换：从“人类半夜爬起来修服务器”到“系统自己判断、自己修复”-26。但市面上大多数自愈工具要么绑定K8s生态，要么只停留在“自动重启”的粗粒度层面。ServerGuard想做的事更朴素：让一台普通的Linux服务器，在没有人盯着的情况下，自己把自己管好。这篇文章不讲故事，只讲架构和设计取舍。一、核心问题：告警驱动的“救火循环” 传统监控工具的架构是： Col

一个中等规模的工厂，1000个传感器，每秒采集一次，一年产生约315亿条数据-26。用MySQL存？一张表315亿行，查询最近1小时的数据要扫描数十万行索引，响应时间从秒级到分钟级-26。写入吞吐量约2万条/秒，加上索引维护和查询并发，实际写入能力急剧下降-26。所以必须用时序数据库。但时序数据库有好几种，选哪个？我用了两年InfluxDB，后来迁到了TDengine，说一下真实感受。Influx

干了这么多年Modbus，我发现一个规律：Modbus很少"突然坏掉"，它通常是慢慢"退化"的。退化的时候不报警、不报错，就是数据偶尔旧一点、轮询周期比配置的慢一点、操作工说"数据好像不太对"。等你发现的时候，已经不是调一个参数能解决的问题了。而且更麻烦的是，Modbus RTU和Modbus TCP的退化机制完全不一样。用排查RTU的思

车联网平台最难的部分，往往不是业务逻辑，而是协议接入。JT/T 808、JT/T 1078、JT/T 809、JT/T 905、JT/T 1045、JT/T 1253、GB/T 32960，每个协议都有自己的解析规则、会话管理和异常场景。如果每个项目都从零实现，团队会陷入无限重复的终端适配和数据库适配中。JTE（JT Engine）是一个开源的 JT/T 部标协议智能引擎，用 Go 语言实现，采用

我们团队做过一个对比实验：场景：开发一个支持 8 种协议的物联网网关，需要完成协议对接、数据映射、异常处理、压力测试。A 组（传统方式）：| 阶段            | 耗时             | 痛点         &nbsp