Stratasys 和 AWS 公开的这套 GrabCAD IoT Platform，讲的是工业 3D 打印机，但里面的问题很常见。设备分散在多个工厂，数据采集口径不齐，故障靠人工追，OT 和 IT 网络还要分段。很多制造业 IoT 项目卡住，也是卡在这些地方。
先别急着谈智能调度
AWS 文章里提到，Stratasys 用 MTConnect 统一传感器数据、状态、使用指标和错误码。这个选择很朴素。设备联网项目如果连状态名称都不一致，后面做看板、告警、工单、预测维护都会变成翻译工程。
我更关注状态账。打印机是在空闲、预热、打印、暂停、维护，还是报警。任务队列里哪个作业在等材料，哪个作业已经失败，哪个错误能自动恢复。状态写不细，现场师傅还是要跑去看机器，系统只剩一个漂亮外壳。
边缘网关要扛住断网
Stratasys 把 AWS IoT Greengrass 放在靠近打印机的网关上，先在边缘做过滤、聚合和本地处理，再把数据送到云端。这个做法适合车间环境。网络抖一下，云端慢一下，设备不能跟着停摆。
边缘侧要有两本账。一本是设备原始事件，尽量保留可追溯细节。另一本是上送云端的规范事件，字段少一点，但要稳定。断网期间先本地落盘，恢复后按版本和时间补发。补发逻辑要测试，别等现场断网才发现顺序乱了。
Device Shadow 适合管期望和现实
AWS IoT Device Shadow 的设计是把 desired、reported、delta 分开。应用写期望状态，设备报告现实状态，差异由服务推给设备。这个模型用在工业设备上很有用，因为现场设备不可能永远在线。
权限要收紧。文档也提醒，更新 shadow 的权限只给可信设备和应用。对制造现场来说，reported 只能由设备或网关写，desired 只能由调度系统或授权应用写。混在一起，排障时没人知道某个状态是机器自己报的，还是后台系统改的。
数据湖不是终点
文章里的数据链路从 IoT Core rules engine 到 Firehose，再进 S3 数据湖，用来支撑分析、审计、合规和模型训练。这个路线没问题，但制造团队容易把数据湖当成项目完成标志。真正难的是数据能不能被车间拿来行动。
例如 OEE 下降，系统要能指出是哪类停机、哪台设备、哪个班次、哪种材料。现场主管需要的是可处理的原因，不是一堆曲线。数据团队和设备团队要一起定义事件粒度，不然模型训练出来也只能证明数据很多。
优易云的落地建议
做设备联网前，先拿一类设备做状态字典。状态、错误码、任务 ID、材料批次、维护窗口、网关版本，全都定清楚。再把边缘断网、重复上报、乱序消息、固件升级失败这些异常路径跑一遍。
平台上线后别只看接入数量。更应该看三件事，故障定位时间有没有变短，现场人工巡检有没有减少，业务系统能不能拿到一致状态。Stratasys 这个案例给人的提醒很直接，IoT 的价值从状态账开始，不从大屏开始。
