摘要：本文来自长三角汽车零配件冲压车间的工业数据开放项目落地经验，针对有机械基础、想做工业数据互联的中级工程师，讲清楚工业数据开放交互API接口服务落地的实际痛点、设计要点和选型避坑经验，所有参数都是现场实测出来的，不是纸上谈兵。
为什么车间里原来的接口方案跑不通
我们之前对接的某头部汽车零配件厂商的冲压车间，六条线十五台冲压机，从十年前的老西门子840D到三年前新上的发那科机器人，再到厂级MES系统，不同供应商的设备数据全封闭在各自的私有系统里。
去年要做冲压模具的预测性维护，需要把实时冲压压力、滑块行程、油温这些数据拉出来给算法团队建模。找原来的设备供应商要接口，开口要十万授权费，排期三个月。
等不及。自己干。
很多人觉得，不就是开个API拿数据吗？互联网上随便搭个服务就能用。说实话，工业现场的环境跟互联网完全不是一回事。断网是常态，设备型号新旧混着来，数据安全要求高，出点错就是停线，停一小时几十万的损失就没了。原来那种封闭的数据交换模式，早就跟不上现在数字化转型的需求了。
国内现在有通用规范，GB/T 38664-2020《信息技术 面向工业领域的应用程序接口（API）规范》，对开放交互的安全性、兼容性都做了明确要求，我们做设计的时候都是卡着这个规范来的。
工业数据开放交互API接口服务的核心设计要点
刚上手做这个项目的时候，我们团队的年轻工程师照着RESTful的范本写了一套接口，测了三天，上线半天就出问题。
哪里错了？没考虑工业现场的实际情况。
第一，必须做离线缓存与断点续传兼容。车间角落的基站信号波动，有时候网络断十几分钟太正常了。如果要求API必须每次实时返回数据，断线的时候整个应用就瘫了。我们最后定的规则是：每个读请求必须带本地缓存时间戳，服务端返回304的时候直接用本地缓存数据；边缘网关本地存断线期间产生的数据，最大缓存窗口7天，网络恢复后按时间戳排序续传。这个参数是测了一个月出来的，大部分现场断网不会超过3天，7天足够，也不会占用太多网关存储。
第二，细粒度到端点的权限管控。别觉得都是厂内部队就可以全开权限。允许能耗分析团队读电流数据，不代表他们能改PLC的冲压参数。我们按照GB/T 33000的要求把数据分成三级：一级公开数据（环境温湿度、产能统计），二级内部共享数据（设备运行参数），三级敏感控制数据（PLC参数、设备配置），每个API端点绑定对应角色权限。之前有个实习生不小心把改参数的接口开给了运维第三方，差点搞出批量报废，真的吓出一身冷汗。
第三，多协议兼容转码不能少。车间一半以上的老设备只支持Modbus RTU协议，你让它输出JSON根本不可能。API服务层必须做协议映射，符合GB/T 19582的标准，把底层的工业协议自动转成开放API需要的JSON格式，不用动设备原有的程序，改起来成本低太多。
选型落地的避坑经验
现在市面上不管是云服务商还是工业互联网平台，都有现成的工业数据开放交互API接口服务，说实话，别上来就买最贵的企业版，得看你自己车间的情况。
如果你的车间大部分都是近五年新上的设备，都带标准OPC UA接口，需求就是快速把数据开放给内部团队用，直接买现成的工业API网关服务就行，成本低，上线快，我们试过最快两周就能跑通全流程。
不过话说回来，如果你的车间老设备多，定制需求多，还要对接多个外部第三方应用，不如自己基于Spring Cloud Gateway做二次开发。我们这个冲压车间就是自己改的，前后花了两个月，但是后续加新设备、开新接口不用每次找服务商收授权费，算下来三年能省小二十万，太香了。
踩过的两个大坑，今天直接说给你，别再掉进去。
第一个坑：没做QPS流控。之前上线测试的时候，第三方算法团队调试，疯狂请求数据，直接把边缘网关的带宽占满了，生产线停了十分钟，赔了五万块。这个亏吃的记一辈子。现在我们每个接口都做租户级QPS限制，普通读数据的接口限制到10QPS，控制类接口限制到2QPS，完全够用，还稳得一批。
第二个坑：不做接口版本管理。改了一个接口的字段，没通知，所有调用这个接口的应用全崩了，排查了两个小时才找到问题。现在我们所有接口都带版本前缀，比如/api/v1/pressure，新接口上线，旧版本保留至少半年，给足够的时间切换，再也没出过这种问题。
真的，工业项目不比互联网，容错率太低了。半点不能偷懒。
我们这个项目上线快一年了，现在模具预测性维护的准确率从原来的62%涨到了89%，每年少停线十好几次，省下的钱远超过当初做API服务的投入。
工业数据开放不是凑数字化转型的KPI，是真的能把躺在设备里的死数据，变成能赚钱的活资产。
