1. 从一条产线改造需求说起为什么是这三个东西凑在一起去年底接了个活儿帮一家做精密结构件的工厂改造一条质检线。需求听起来不复杂把原来靠人眼看的表面缺陷检测换成自动识别识别结果要实时上传到云端做统计分析同时车间主任希望在手机端就能看到每条产线的实时良率。三个诉求拆开看都不新鲜但真正落地的时候问题就来了——视觉识别算法跑在工控机上数据怎么稳定上云云端的数据怎么变成车间主任看得懂的看板看板背后的应用谁来开发、怎么迭代这三个问题对应的恰好就是标题里的三块拼图工业视觉识别负责看IoTDA 物联网平台负责传CodeArts 应用开发负责用。很多人做工业项目容易犯一个毛病就是把这三件事割裂开来看视觉团队只管算法准确率物联网团队只管设备接入应用团队只管页面好不好看结果三拨人各干各的联调的时候互相甩锅。我踩过这个坑所以这篇就把这三块怎么串成一条线讲清楚。先说清楚这篇适合谁看。如果你是从传统自动化转过来的工程师对视觉和云平台都只停留在概念层面这篇能帮你建立完整的链路认知如果你是做软件开发的想切入工业场景这篇能让你明白工业现场和互联网场景的本质差异在哪如果你是项目负责人正在评估一条智能质检线的技术方案这篇能帮你判断哪些环节是真正的风险点。全文不讲虚的都是我在实际项目里验证过的路径和踩过的坑。需要提前说明的是工业视觉识别这个领域非常宽从简单的尺寸测量到复杂的缺陷分类技术路线差异极大。这篇聚焦的是基于深度学习的表面缺陷检测这个细分场景因为这是目前工厂改造需求最集中的方向也是和 IoTDA、CodeArts 结合最自然的场景。其他场景比如OCR字符识别、3D点云测量链路的思路相通但具体参数和工具选型会有区别我会在相关章节点出来。2. 工业视觉识别在产线上的真实工作边界2.1 别被识别准确率99%这种数字忽悠刚入行的时候我也迷信准确率觉得算法跑出个99.5%就万事大吉了。实际部署到产线上才发现实验室里的准确率和产线上的准确率完全是两码事。实验室用的是标注好的数据集光照、角度、背景都是可控的产线上呢车间灯光会随时间段变化产品在传送带上的位置有抖动镜头用久了会积灰甚至季节变化导致的温湿度差异都会影响成像质量。所以我在项目里评估视觉方案时从来不看单一准确率指标而是看三个东西漏检率、过杀率和稳定性。漏检率是缺陷产品被放过的比例这个直接关系到客户投诉必须压到极低过杀率是良品被误判为缺陷的比例这个关系到生产成本太高了工厂不干稳定性是指连续运行8小时以上各项指标不出现明显漂移。这三个指标之间是相互制约的你把漏检率压到零过杀率必然飙升反之亦然。实际项目里要根据客户的质量要求和成本承受能力找一个平衡点。具体到技术实现我一般会建议客户在产线上部署边缘推理而不是云端推理。原因很简单工业场景对延迟极其敏感传送带速度如果是每秒0.5米从相机拍照到分拣机构动作留给算法的时间窗口可能只有几十毫秒。数据传到云端再传回来光网络延迟就不止这个数。所以视觉识别这一层必须在本地完成用工业相机加边缘计算盒子比如带GPU的工控机或者专用的AI推理盒子的架构。2.2 从打光到推理一条完整的视觉链路拆解很多人以为视觉识别就是调个模型其实模型只是最后一环。一条完整的工业视觉链路从物理层到应用层我习惯把它拆成六段第一段是打光。这是最容易被忽视但最影响效果的一环。同样的缺陷用环形光、条形光、同轴光、背光打出来成像效果天差地别。比如检测金属表面的划痕用低角度条形光斜射划痕会因为漫反射呈现为亮线对比度极高如果用正面同轴光划痕几乎看不见。我一般会建议在方案阶段就做打光测试拿实际样品在多种光源下拍一圈选出缺陷最明显的那种组合。这一步花两天时间能省后面两周的调参时间。第二段是成像。相机选型要看三个参数分辨率、帧率和接口。分辨率决定了能看清多小的缺陷一般要求缺陷在图像上至少占3到5个像素反推需要多少万像素的相机。帧率要匹配产线速度如果每秒过10个产品相机帧率至少要到15帧留余量。接口方面GigE和USB3.0是主流GigE传输距离长适合产线布局USB3.0带宽高适合高帧率场景。第三段是预处理。包括去噪、增强、ROI裁剪。ROI裁剪特别重要把图像裁到只保留产品区域能大幅减少后续计算量。我见过有人把整张2000万像素的图直接喂给模型推理时间直接爆掉裁到200万像素的ROI之后速度提升十倍不止。第四段是推理。模型选型上工业缺陷检测目前主流是YOLO系列做检测、UNet系列做分割。YOLOv8在精度和速度的平衡上做得不错适合大多数场景。如果缺陷形态复杂、边界模糊用分割模型效果更好但推理速度会慢一些。模型训练的数据量我的经验是每类缺陷至少准备200到300张标注样本太少容易过拟合太多标注成本扛不住。第五段是后处理。模型输出的原始结果往往不能直接用需要做置信度过滤、NMS去重、面积过滤等。比如模型可能把同一个缺陷框出好几个重叠的框NMS就是用来合并这些框的。面积过滤是排除那些太小的误检比如几个像素的噪点。第六段是结果输出。识别结果要格式化成结构化数据包含产品ID、检测时间、缺陷类型、缺陷位置、置信度等字段。这个格式直接决定了后面 IoTDA 怎么接入、CodeArts 怎么展示所以要在视觉这一层就定好数据契约不然后面联调会反复改。2.3 边缘侧和云侧的分工怎么划这是我在项目里被问得最多的问题哪些计算放边缘哪些放云端我的划分原则是实时性要求高的放边缘统计分析类的放云端。边缘侧负责图像采集、预处理、模型推理、结果判定、和PLC通信控制分拣机构。这些环节对延迟要求在毫秒级必须在本地闭环。云侧负责历史数据存储、良率趋势分析、多产线对比、报警推送、报表生成。这些环节对延迟不敏感但对数据量和计算弹性要求高放云端更合适。中间还有一个边缘网关的角色负责把边缘侧的结果数据打包上传到 IoTDA。这个网关可以是工控机上跑的一个服务也可以是独立的物联网网关设备。我一般倾向于用软件网关部署灵活升级方便。3. IoTDA 接入把产线数据稳定送上云的关键细节3.1 设备建模别把产品当设备要把产线当设备第一次用 IoTDA 的时候我犯了个想当然的错误把每个产品当成一个设备上报数据。结果一条产线一天过几万个产品设备数直接爆炸管理界面卡得打不开。后来才想明白IoTDA 里的设备应该对应物理实体也就是产线或者工位产品数据是设备上报的消息不是设备本身。正确的建模方式是这样一条产线注册为一个设备设备下面定义产品属性比如产线编号、所属车间、负责工序然后通过物模型定义上报的数据结构。物模型是 IoTDA 的核心概念说白了就是用 JSON Schema 描述这个设备能上报哪些属性、能响应哪些命令。比如定义一个质检结果属性类型是结构体里面包含产品ID、缺陷类型、置信度等字段。物模型定义好之后边缘网关就按照这个格式上报数据。这样做的好处是云端不需要关心边缘侧用的什么算法、什么相机只要数据格式符合物模型就能正常解析和存储。后面如果换了视觉方案只要物模型不变云端应用完全不用改。3.2 MQTT 连接的那些坑心跳、QoS 和断线重连IoTDA 支持 MQTT、CoAP、HTTP 等多种接入协议工业场景我强烈建议用MQTT。原因有三个一是长连接不用每次上报都建连接延迟低二是支持发布订阅天然适合一对多的数据分发三是协议轻量对边缘设备的资源占用小。但 MQTT 用起来有几个坑必须注意。第一个是心跳间隔。MQTT 的 Keep Alive 参数决定了客户端多久没发消息就发心跳包。设太短网络流量浪费设太长连接断了半天才发现。我的经验值是30到60秒配合服务端的遗嘱消息机制连接异常断开时能及时感知。第二个是 QoS 等级。MQTT 有三个 QoS0是最多一次1是至少一次2是恰好一次。工业质检数据我一般用 QoS 1保证数据不丢但可能重复。重复数据在云端做去重处理比丢数据好处理得多。QoS 2虽然不丢不重但握手开销大高并发场景下反而容易成为瓶颈。第三个是断线重连。车间网络环境不比机房网线被叉车压断、交换机重启都是常事。边缘网关必须实现自动重连而且重连后要能续传断线期间的数据。我的做法是在网关本地做一个环形缓冲区数据先写本地上报成功后再删除。断线期间数据积压在缓冲区重连后按顺序补传。缓冲区大小根据断线时长和上报频率算一般留够半小时的数据量。3.3 数据上报频率和批量策略的权衡上报频率这个事没有标准答案要看下游应用的需求。如果车间主任的看板要求秒级刷新那上报频率至少要到秒级如果只是做日报表分钟级上报就够了。但频率越高对 IoTDA 的压力越大流量成本也越高。所以我的策略是分级上报实时性要求高的数据比如缺陷报警立即上报实时性要求低的数据比如良品计数批量上报。批量上报可以攒够一定条数或者等一定时间间隔再发减少连接开销。具体参数上我一般设两个阈值攒够50条上报一次或者每10秒上报一次哪个先到触发哪个。这样在产线高速运行时走条数触发低速运行时走时间触发兼顾了实时性和效率。还有一个细节是消息体大小。MQTT 单条消息不建议超过128KB太大了容易传输失败。如果单次上报的数据量大要么拆成多条要么做压缩。我一般会把 JSON 字段名做短化处理比如product_id写成pid能省不少字节。4. CodeArts 应用开发让数据变成车间看得懂的东西4.1 从需求到应用车间主任到底要看什么做应用开发最怕的就是闭门造车。我见过有团队花两个月做了个功能极其丰富的看板结果车间主任根本不用因为操作太复杂。后来我去车间蹲了半天发现主任真正关心的就三件事当前良率是多少、哪条线在报警、今天的趋势是变好还是变坏。所以应用设计的第一原则是信息层级要扁平。打开应用第一屏就要看到核心指标不要让人点三层菜单才能找到。我的做法是首页放三个卡片实时良率大字号、报警列表滚动、趋势图折线。这三个卡片覆盖了80%的日常查看需求剩下的细节查询放到二级页面。CodeArts 在这块的优势是提供了低代码开发能力拖拽组件就能搭页面不用从零写前端。对于工业场景这种页面不复杂但数据对接繁琐的需求低代码能省大量时间。但要注意低代码不是万能的复杂的交互逻辑和自定义图表还是得写代码CodeArts 支持在低代码页面里嵌入自定义组件这个能力要善用。4.2 数据流打通从 IoTDA 到应用层的数据管道IoTDA 的数据要到应用层中间需要一个数据流转的通道。IoTDA 本身提供了规则引擎可以配置规则把设备上报的数据转发到其他云服务比如转发到数据库、转发到消息队列、或者通过 API 推送给应用。我的常规做法是IoTDA 规则引擎把数据转发到一个消息队列比如 Kafka 或者云上的消息服务应用层从消息队列消费数据写入自己的业务数据库。这样做的好处是解耦IoTDA 不用关心应用层怎么处理数据应用层也不用关心数据从哪个设备来双方通过消息队列这个中间层对接。数据库选型上工业时序数据我推荐用时序数据库比如 InfluxDB 或者云上的时序数据库服务。原因是一天的质检数据可能几十万条用传统关系型数据库查询趋势图会越来越慢时序数据库针对时间范围查询做了专门优化性能差距是数量级的。应用层的数据处理逻辑要包括数据清洗去掉重复和异常值、数据聚合按小时/班次/天做统计、报警判定连续N个缺陷触发报警。这些逻辑可以放在应用后端也可以用流处理框架做。数据量不大的话应用后端直接处理就够了不用上流处理那么重的架构。4.3 报警推送和移动端适配的实操经验报警推送是车间最看重的功能之一。但推送有个度的问题推太频繁大家就麻木了真报警也没人看推太少又怕漏掉重要问题。我的做法是分级报警单次缺陷不推连续3个缺陷推黄色预警连续5个缺陷推红色报警。黄色预警只推到应用内红色报警同时推短信或应用推送。移动端适配这块CodeArts 支持响应式布局一套页面能适配PC和手机。但工业场景有个特殊需求车间里工人可能戴着手套操作触控精度低所以按钮要做大最小点击区域不小于44像素。另外车间光线可能很暗或者很亮配色要有足够的对比度别用浅灰配白色这种看不清的组合。还有一个容易被忽视的点是离线可用性。车间网络不稳定的时候应用要能显示最后一次同步的数据而不是白屏。这个需要在应用层做本地缓存CodeArts 的低代码框架一般有缓存机制但要配置好缓存策略和过期时间。5. 三块拼图拼起来一次完整的联调踩坑记录5.1 时间戳对不上一个折腾了两天的低级问题项目联调阶段遇到的第一个大坑是视觉侧上报的时间和云端显示的时间差了8小时。排查过程很典型值得记录一下。第一步确认边缘侧的时间。登录工控机date命令一看系统时间是准的。第二步确认上报数据里的时间戳。抓包看 MQTT 消息时间戳字段也是对的。第三步确认 IoTDA 收到的时间。在 IoTDA 的控制台看设备上报日志时间显示正常。第四步确认应用层显示的时间。到这里发现问题了应用层把时间戳当成本地时间解析了而时间戳本身是 UTC 时间所以显示出来差了8小时。这个问题本质上是时区处理不规范。正确的做法是全链路统一用 UTC 时间戳传输只在最终展示的时候转换成用户所在时区。边缘侧生成时间戳用 UTCIoTDA 存储用 UTC应用层展示时再转。这个规范要在项目一开始就定好写进接口文档不然后面每个环节都可能出问题。5.2 数据丢包从怀疑网络到发现是缓冲区溢出第二个坑更隐蔽。测试的时候发现产线高速运行时云端收到的数据比实际检测的数量少。一开始怀疑是网络丢包但用 QoS 1 理论上不会丢。查了网络监控带宽和延迟都正常。后来在边缘网关的日志里发现了线索缓冲区满的警告。原来网关的环形缓冲区设得太小产线高速运行时数据产生速度超过了上报速度缓冲区很快写满新数据覆盖了旧数据。这个问题在低速测试时完全暴露不出来只有满负荷运行才会出现。解决办法有两个一是加大缓冲区二是提高上报吞吐。我两个都做了缓冲区从1000条加到10000条同时把批量上报的条数阈值从50降到20提高上报频率。改完之后再测数据一条不差。这个坑给我的教训是测试必须模拟满负荷场景。低速测试通过不代表高速没问题缓冲区、队列、连接池这些资源在高压下才会暴露瓶颈。5.3 应用层卡顿时序数据查询没建索引的代价第三个坑出现在应用上线一周后。车间主任反馈说看板越来越卡刚开始秒开后来要等十几秒。登录服务器一看数据库查询慢得离谱。原因很简单趋势图查询要扫描全表。一周积累了上百万条数据每次查询都全表扫描不慢才怪。解决办法是给时间字段建索引同时做数据分区按天分区查询时只扫对应分区。改完之后查询时间从十几秒降到几百毫秒。这件事让我意识到工业应用的数据增长速度和互联网应用不一样。互联网应用可能用户量很大但单个用户的数据量不大工业应用用户不多但设备持续不断产生数据单表数据量增长极快。所以时序数据的索引和分区策略必须在设计阶段就考虑不能等出了问题再补。6. 几个让项目少走弯路的经验总结6.1 数据契约先行接口文档比代码更重要这三个模块分属不同技术栈视觉是Python网关可能是C或Go应用是Java或JavaScript。跨语言协作最容易出的问题就是数据格式对不上。我的做法是在写第一行代码之前先把数据契约定死。数据契约包括字段名、字段类型、单位、精度、必填还是选填、取值范围。比如缺陷置信度是0到1的小数还是0到100的整数保留几位小数这些细节不写清楚联调时就是无尽的扯皮。我一般会用 JSON Schema 把契约写出来各方照着 Schema 开发联调时用 Schema 做校验能省大量沟通成本。6.2 灰度上线别一次性替换整条产线工业项目和互联网项目最大的区别是停线成本极高。一条产线停一小时损失可能几万到几十万。所以上线策略必须保守我强烈建议灰度上线。具体做法是先在一台工位上部署新系统和原有的人工检测并行运行对比两者的结果。运行一周确认新系统的漏检率和过杀率都达标再扩展到整条产线。整条产线跑稳了再复制到其他产线。这样即使新系统有问题影响范围也可控。灰度期间要重点看两个指标新系统和人工检测的结果差异率以及新系统自身的稳定性有没有崩溃、重启。差异率高的样本要人工复核确认是新系统错了还是人工漏了。这个过程虽然慢但能避免上线后的大事故。6.3 留一手边缘侧必须能独立运行最后一个经验是关于降级方案。云端再稳定也有出故障的时候。网络断了、IoTDA 服务异常、应用服务器宕机这些情况都可能发生。如果边缘侧完全依赖云端云端一挂整条产线就瘫了。所以边缘侧必须能独立运行。具体来说视觉识别和分拣控制这个闭环要在本地完成不依赖云端。云端只负责数据展示和分析云端挂了产线照常运行只是看板暂时看不到数据。等云端恢复边缘侧把积压的数据补传上去。这个设计原则说起来简单但实现的时候容易被忽略。比如有人把报警判定逻辑放在云端云端一挂缺陷产品就没人管了。正确的做法是报警判定在边缘侧做云端只做报警的展示和推送。边缘侧判定为缺陷直接控制分拣机构剔除同时把报警信息上报云端。这样即使云端不可用产线也不会流出缺陷产品。我在实际项目里还遇到过一种情况客户为了省钱边缘计算盒子配置很低跑视觉模型已经很吃力再让它跑复杂的业务逻辑就扛不住了。这种时候我的建议是分清主次边缘侧只保留最核心的推理和分拣逻辑其他能上云的上云。如果预算实在有限宁可降低视觉模型的分辨率或者帧率也要保证核心闭环的稳定性。毕竟产线不停比检测精度高几个百分点重要得多。这套方案后来在三条产线上复制部署从第一条线的两周联调到第三条线的三天上线踩过的坑都变成了标准流程。工业项目就是这样第一次做处处是坑把坑填平了后面就是流水线作业。希望这些经验能帮到正在做类似项目的同行少走点弯路。