摘要：本文基于多年汽车车间数字化改造的一线经验，围绕工业数据开放交互API接口的设计、选型与落地，分享实际项目里的权衡和踩坑教训，给有一定基础的中级工程师做参考。
为什么工厂现在离不开工业数据开放交互API接口
三年前我在华东某整车厂做冲压车间的数字化改造，碰到一个极其头疼的问题。整条线五台冲压机是济南二机床的，六台上下料机器人是KUKA的，线尾检测是发那科的视觉系统，MES是客户自己信息部开发的。原来要打通各设备的数据，要么走硬接线采点，改一次加十几个点要停线两天，要么找各个设备厂商要私有接口，开口就要二十万授权费，还不给文档，只给个调用包，出问题连查都没法查。
那时候才真的明白，开放标准化的API接口对工业场景来说，不是锦上添花的花活，是能帮项目省几十万、提前几个月交付的硬需求。
原来那种各个厂商封闭做系统的时代早就过去了，现在客户要把所有数据拉去做 predictive maintenance，要做数字孪生，没有开放的API接口，一切都是白搭。
工业场景设计开放交互API接口的核心硬约束
很多刚从互联网转工业数字化的朋友，容易犯一个错：把互联网的RESTful API直接拿过来用，根本不管工业场景的特殊要求。说实话，这能跑成才怪。
我们现在做设计，首先要对齐GB/T 39116-2020《智能制造 工业互联网平台 应用编程接口(API)规范》里的要求，这个是行业通用的基准，所有接口定义都要往上面靠，少很多扯皮的事。
第一个硬约束是传输时延。工业场景里，运动控制类、实时状态类的数据，端到端时延要求通常在10ms以内，比互联网API动辄几百ms的容忍度严了几十倍。我们早年试过直接用RESTful传冲压机的实时压力曲线，高峰期网络一挤，时延直接飘到200ms，导致数字孪生的仿真刷新不同步，偏差差出了半个厘米，根本没法用。亏了三个冲压件，小两万打了水漂。那心疼劲，现在还记得。
现在我们的选型逻辑很清晰：对实时性要求高的设备数据交互，用OPC UA的二进制编码API，时延能稳定控制在5ms以内，满足绝大多数运动控制和实时采集需求；对非实时的、比如工单下发、报表查询这类业务，用RESTful就够了，开发快兼容性好，不用瞎折腾。
第二个硬约束是兼容性和安全性的平衡。开放不是裸奔，工业API接口一旦被非法调用，改个生产线节拍或者设备参数，那就是停线的大事。我们前年碰见过第三方运维团队，调接口的时候没做权限校验，不小心把冲压机的闭合压力改了十个百分点，直接导致模具损伤，停线四个小时，赔了几十万。
所以现在我们做所有开放接口，每个调用方都要做设备级的身份认证，每个接口都分读写权限，只读的接口绝对不给写权限，这个底线不能松。对老设备的兼容也要考虑，很多工厂里还有用了十几年的老设备，只支持Modbus RTU，那API就要做好协议封装，把Modbus的指令转成标准化的开放接口，调用方根本不用管底层是什么协议，拿过来就能用。
落地时容易忽略的几个隐形坑
第一个坑，数据格式不统一。同样是设备定子温度，甲厂商的API返回摄氏度，乙的返回开尔文，丙的单位对了但精度是小数点后三位，丁的是整数，对接的时候光调格式就要花一周，还容易出低级错误。我们现在做接口规范，强制要求每个返回字段必须带单位和精度说明，写入规范里，谁都不能改，少了好多破事。
第二个坑，没做流量管控。工业传感器一秒就能出好几个数据，一条生产线一分钟就是上百兆的时序数据，你放开了让调用方随便拉，分分钟把边缘网关的带宽占满，别的业务直接断了。我们现在给每个调用方都做了Qps限流，最大并发不超过约定值，大的数据集请求强制要求做压缩，用gzip压完之后，压缩比能到10:1，带宽压力一下就下来了，好用得很。
第三个坑，版本兼容没做好。之前我们改了一版接口，把设备状态的字段名从dev_state改成了device_status，没留旧版本，结果有个第三方的质量分析系统半年没人维护，对接直接崩了，停线找问题找了大半天。说实话，这个锅完全在我们。现在我们做接口迭代，至少保留两个旧版本在线，发布新版本之后提前三个月通知所有调用方，半年之后才会下线旧版本。不过话说回来，也别留太多旧版本，维护起来真的累死，对吧？
很多人说现在工业API网关很火，其实工业场景下的网关和互联网的不一样，一定要做边缘侧的网关部署，把大部分接口调用放在车间本地处理，不用都往云端传，既降时延又省带宽，这个是实际跑过项目才懂的道理。
工业数据开放交互API接口，从来不是把互联网的API换个名字套个工业壳就完了。它要适配工业场景的硬约束，要解决老设备兼容、安全性、实时性这些互联网场景碰不到的问题，多踩几次坑，自然就知道该怎么设计了。
