ITPub博客

我在工业物联网行业待了几年，听过最多的一句话是：“边缘算力不够，AI必须上云。”说这话的人，要么是卖云服务的，要么是没在工厂待过的。先看一组真实数据 我统计了我们部署过的37个工业AI场景，推理任务分布是这样的：任务类型 占比 算力需求 异常检测（振动/温度/电流） 52% 极低，ONNX模型<10MB 趋势预测 21% 低，ONNX模型<50MB 视觉检测 18% 中，需NPU或GP

一个让我想了很久的问题 上个月有个做集成的朋友找我，说想用我的开源国标平台，但有个顾虑。“你以后会不会突然收费？或者把核心功能藏起来，逼我买商业版？”我说不会，AGPL v3.0协议，代码全部开源，永远免费。他说：“那你图什么？”这个问题我被问过很多次。今天认真聊聊。开源不等于不赚钱 很多人对开源有个误解：开源就是做慈善，作者不赚钱，纯靠爱发电。不完全是。开源项目的商业模式有很多种：技术支持： 代

做 JT/T 808 开发，校验码算错是最高频的问题。我见过有人查了一整天，最后发现是转义处理漏了消息头。也见过有人把 BCD 高低位搞反，终端手机号解析出来全是乱码。今天把最常见的 3 个坑列出来，你对号入座。坑一：转义处理只做了消息体，没做消息头。JT/T 808 用 0x7E 作为帧头帧尾，0x7D 作为转义字符。很多人写转义处理时，只对消息体做了 0x7D02 和 0x7D01 的替换，忘

评论区“林间隐居宁静致远”的项目，有一个细节值得深挖。他的校园洗衣机项目，用的是Netty + 自定义TCP协议。也就是说——协议是他自己设计的。“自己写协议”这个事，在工控圈里有争议。有人说：“有标准协议为什么不用？Modbus、MQTT、OPC UA都是现成的，非要自己造轮子。”有人说：“标准协议满足不了我的需求，我就自己写。”到底该不该自己写协议？先说一个真实案例。一个做充电桩的公司，早期用

一、一个真实项目的教训 去年我参与了一个政务系统的信创迁移项目，从Oracle 11g迁到达梦DM8。达梦的一个卖点是“高度兼容Oracle”，官方文档也强调PL/SQL语法兼容。项目组一开始很乐观——既然兼容，迁移应该很顺利。但实际迁移中，我们遇到了几个意想不到的问题。二、兼容性带来的“隐性陷阱” 陷阱一：隐式类型转换的行为不一致。Oracle中，WHERE varcharcol = 123会自

先说结论 做国标视频平台，流媒体服务器我最终选了ZLMediaKit，放弃了SRS。不是因为SRS不好。SRS在互联网直播领域非常优秀，RTMP推流、HTTP-FLV/HLS拉流做得扎实，社区活跃，文档完善。但国标场景不一样。为什么一开始选SRS？ 去年开始做国标平台的时候，我第一反应是用SRS。理由很简单：SRS名气大，用户多，出了问题好搜答案。而且SRS 5.0开始支持GB28181，通过st

去年入职一家做车联网平台的公司，第一天开技术会，CTO 明确说了一句：“公司项目禁止使用来源不明的开源工具，出了问题谁负责？”我理解他的顾虑。商业工具有人兜底，自研工具可控，开源工具确实存在维护风险、安全风险、合规风险。但问题是，我们当时做 JT/T 808 联调，商业工具报价六位数，自研来不及，团队只能靠手写脚本硬扛。我偷偷下载了 JT-Simulate。为什么敢用？因为它开源，代码就在那里。我

评论区有位兄弟说他在工业园区用MQTT，每个网关连100个设备左右，跑了一年半了。这是个好案例。但我也见过很多MQTT项目一上量就崩——几千个设备同时在线，Broker就扛不住了。为什么有的项目100个网关稳稳当当，有的项目几千个设备就崩了？第一个坑：Broker选型不对。MQTT Broker有好几种——Mosquitto、EMQX、HiveMQ、VerneMQ、NanoMQ。Mosquitto

SPIFFE 是 CNCF 的毕业项目，Kubernetes 生态里管身份认证的事实标准。但它最初设计时面对的是云原生工作负载——K8s Pod、VM、Serverless 函数-23。没人想过用它来管一个 Modbus 传感器的身份。但我做了。问题：一个工厂 5000 台设备，每台都是一个潜在的后门 传统 IoT 设备靠 IP/MAC 地址识别身份。这意味着什么？任何知道设备 IP 的人，插上网

上个月帮一个做设备运维的朋友选边缘 AI 平台。他的需求很朴素：工厂里有 200 台设备，装了振动和温度传感器，想做个异常告警，预算不高，不想换硬件，不想数据上云。我陪他测了 5 个平台，结果挺意外的。测试对象和结果平台部署耗时最低内存断网可用多模型编排本地 LLM硬件绑定AWS Greengrass2 天1GB+部分❌❌倾向 AWSAzure IoT Edge1.5 天1GB+❌❌❌倾向 Azu

前年接了一个道路运输平台的项目，需要解析 JT/T 808-2019 的位置上报报文。我当时的想法很简单：协议文档又不复杂，自己写一个解析器，可控、可定制、不依赖第三方。于是我花了 3 天，写了转义处理、校验码计算、BCD 解码、大小端转换，还写了一套单元测试。本地跑了几十条构造报文，全部通过。我当时觉得自己挺牛。然后真实终端接进来了。第一条报文就把我的解析器干崩了。终端手机号解析出来是乱码。我查

上篇文章《用Netty还是MQTT》发出去之后，评论区吵起来了。有个兄弟说“瞎扯淡”。然后“林间隐居宁静致远”本人来了，说那段评论确实是他写的——他用Netty做了7年校园洗衣机项目，几十万台设备，稳定运行；后来做工业园区用MQTT，每个网关连100个设备，也跑了一年半。两段真实的项目经历，两种完全不同的技术选型。到底谁对？我说点更具体的。先还原一下两个项目的真实场景。项目A：校园智慧洗衣机（Ne

这句话会得罪很多人。但我还是要说。一个真实项目去年，一个客户找我做技术咨询。他们的车联网平台上了微服务，拆了30多个服务。我问他：为什么拆这么多？他说：微服务架构啊，高内聚低耦合，独立部署，技术异构。我说：你们多少终端？他说：5000台。5000台终端，30个微服务。平均每个服务承载166台终端。微服务在车联网的典型问题第一，网络开销。微服务之间通过HTTP或gRPC通信。一次位置上报，网关服务要

MQTT这几年被捧得很高。很多方案里，不管什么场景，先上一个MQTT Broker再说。但我用了3年MQTT之后发现——MQTT在工业现场有4个场景是真的不适合，硬用只会给自己找麻烦。场景一：安全联锁回路。一个化工项目，安全联锁系统需要在检测到压力超标后50ms内切断进料阀。有人提议“用MQTT下发切断指令，快得很”。这是要命的错误。MQTT的消息从发布者到Broker再到订阅者，中间经过了至少两

每次在团队里推荐开源工具，总会有人问：“开源的东西，出了问题谁负责？”“代码质量能保证吗？”“会不会有安全风险？”我做部标协议开发六年，用过自研工具、商业工具、开源工具。说实话，没有哪个工具是完美的。商业工具支持好，但贵，而且定制困难。自研工具可控，但维护成本高，人员一流动就没人管了。开源工具免费，但需要自己判断质量。JT-Simulate 是我半年前开始用的。当时项目要做 JT/T 808 和

选型背景 做国标视频平台，流媒体服务器是绕不开的环节。主流选择有两个：SRS和ZLMediaKit。SRS 定位是互联网直播，RTMP推流、HTTP-FLV/HLS拉流做得非常扎实，社区活跃，文档完善-29。ZLMediaKit 更均衡，RTSP、RTMP、HLS、HTTP-FLV、WebRTC全都支持，尤其对GB28181和安防场景适配更好-29。两个我都部署过，踩了不少坑，今天把对比和选型建议

评论区有个兄弟说了一句话，我看了三遍。“我做校园智慧洗衣机，一个学校3千到1万台，200个学校，几十万台设备，要求实时控制，我用Netty做了7年，很稳定。现在做工业园区智慧管理，用MQTT，每个网关连接100个设备左右，做了一年半了。”这短短两段话，把工业物联网协议选型最核心的矛盾说透了。同样是物联网项目，为什么第一个选了Netty，第二个选了MQTT？为什么两个都能跑？今天我不站队，把Nett

这个问题在车联网圈子里几乎每年都要吵一次。做道路运输的坚持 JT/T 808，做新能源的力推 GB/T 32960。去年我接了一个混合项目：既要对接道路运输车辆，又要接入新能源车。两个协议都要支持，而且要在同一个平台上调试。一开始我们想得简单：JT/T 808 和 GB/T 32960 各写各的解析器，各调各的设备。结果调试阶段直接崩溃。JT/T 808 用 7E 转义，GB/T 32960 用

一个化工厂的项目，上百台老旧设备，大部分都是10年前的老家伙，通过Modbus和CAN总线连接。老板想搞预测性维护，减少非计划停机。听起来很美好。但到现场一看：设备分散在几个车间，有些地方连网线都拉不过去；现场温度经常超过50℃，灰尘、震动、电磁干扰样样不缺；最要命的是，很多地方只有24V工业电源，功率预算极其有限。这就是工业AI边缘部署的真实环境——不是实验室，不是演示厅，是真实的、恶劣的、处处

前年做一个部标平台项目，甲方要求：“上线前必须做 500 台终端并发测试，而且必须用真实设备。”采购 500 台终端是什么概念？硬件成本、SIM 卡、流量费、场地、电源，加起来六位数。更麻烦的是，真实终端型号杂，行为不一致，压测结果根本不可控。有的终端心跳间隔 30 秒，有的 60 秒；有的注册完立刻鉴权，有的要等 5 秒。团队吵了一周。一派说真实设备才靠谱，另一派说仿真工具足够。最后折中：先用