上周实训课的“死机事故”
上周带大三上智能夹具设计的实训课，亲眼见着第三组的两台设备当场僵住。原因说出来有点好笑——他们把夹具上贴的三个振动传感器、两个夹紧力传感器的所有采样值，每秒200组全传到云平台做实时监测，那天车间角落的WiFi路由器被搬去临时装设备，断了12分钟网。
没有云端的指令，夹具连最基础的夹紧动作都不敢执行。
最后等网络恢复的时候，夹头已经松松垮垮蹭在工件表面，半块铝料被刮得全是毛刺，地上散了一堆铝屑。
我站在旁边看着那堆铝屑，头都大了。
有个学生挠着头跟我解释，说课本上的振动监测、夹紧力异常判断的模型，都是在服务器上跑的啊，本地就一个8位的小MCU，哪有算力算这些东西。
我当时没接话。其实这个问题我自己刚进教研室的时候也纠结过——总觉得做机械设计的，只要把结构画对、材料选对就行，那些数据运算的事，是电子专业的人该管的。直到去年去合作的制造企业跟了三个月的设备调试，才被现实拍了一耳光：车间里的网络根本不可能像写字楼里那样稳，要是每台设备都等着云端发指令，那生产停起来的损失，比买十块运算模块都贵。
我们给实训课做的“降维改造”
回来之后就跟教研室的同事商量，把原来的实训内容改了。之前的流程是学生写完传感器采集代码，直接接云端平台，调通算法就算完成项目。现在加了一个必选环节：所有涉及安全的判断，必须在本地完成，不能等云端的响应。
说起来简单，做的时候全是取舍。
最开始大家想的是把整个振动监测模型直接塞到夹具上搭载的STM32H7模块里，结果算下来内存要占快90%，跑个十几秒就内存溢出。后来翻之前几届学生留下来的项目存档，看到有个2021级的学长做过类似的事：把原来需要全量数据输入的FFT变换，简化成只提取6个特征频率的峰值，不需要存完整的采样波形，内存占用直接砍了80%。
我们顺着这个思路改了逻辑：正常生产过程中，振动、夹紧力、温度的数值只要在预设的安全区间内，根本不需要往外传，本地直接按预设流程走动作就行。只有当数值偏离阈值超过10%，或者检测到之前标记过的故障频率特征，才把对应时间窗口的数据包传去云平台，做后续的寿命预测、故障溯源。
说真的，我第一次测这套方案的时候，特意把车间的WiFi总闸拉了，夹具照样能正常完成夹紧、异常报警、急停的全套流程，那种爽感，比我自己评上高级职称还开心。
边缘侧本地数据运算处理的核心从来不是“替代云端”，而是把最紧急、最不能等的判断，放在离动作最近的地方。你想啊，要是夹紧力掉了，工件马上要飞出来，这时候你等个几百毫秒的网络延迟收云端的指令，那出了事就是安全事故，根本没有补救的余地。但要是算一下这个夹具的累计使用时长，预测下一次换密封件的时间，就算这个数据晚个十秒传到平台，又有什么影响呢？
被学生问住的两个“为什么”
第一个是个戴黑框眼镜的男生，下课堵在讲台边问：“老师，要是本地的判断逻辑错了怎么办？比如把正常的振动当成异常，直接触发急停，一整线的设备都停了，那损失不是更大？”
我当时愣了两秒。之前我自己备课的时候，总觉得本地运算就得做到100%准确，不然为啥要做。后来跟工厂里做了十二年设备维护的李师傅聊天，人家说的话才叫实在：现场哪有100%准确的判断？你本地先把最要命的情况兜住——比如夹紧力骤降、振动突然飙升，这时候不管你逻辑准不准，先触发急停，哪怕是误报，停个几秒检查一下，总比工件飞出来砸人强。剩下的非紧急的判断，你慢慢传去云平台算，哪怕算慢个几十秒，根本不影响现场安全。
第二个问题更实在：“我们是学机械设计的，花这么多时间研究本地运算，是不是以后要跟嵌入式专业的同学抢工作啊？”
这话给我逗笑了。哪能啊。
我们学这个，根本不是让你自己从零写一套嵌入式算法。是你以后做机械结构设计的时候，得知道你设计的这个部件，哪些数据是必须本地处理的，哪些可以往外传；你给运算模块留的安装空间够不够，散热路径顺不顺，供电线的线径能不能扛住模块的峰值电流。之前有个小组交的设计图，把运算模块直接装在夹具的夹紧腔旁边，夏天车间温度40度，模块跑半小时就过热死机——这不就是没考虑到本地运算的实际工况吗？你结构设计的时候多留两厘米的散热空间，比你事后改十行代码都有用。
上周改实训大纲，我把原来占8课时的云端算法调试内容，砍了3课时，换成边缘侧本地数据运算处理的取舍练习。给学生一套传感器参数，让他们自己选哪些数据要本地处理，哪些可以上传，算一算本地模块的功耗、内存占用、需要的安装空间。
上次收上来的作业，有个小组甚至给运算模块加了个小小的铝制散热片，贴在夹具的非运动面上，连散热风道的方向都顺着车间的通风流向做的，我批作业的时候，真的觉得比那些抄来的满是专业术语的漂亮PPT有用多了。
昨天那个之前断网就死机的第三组，自己改了程序之后，在车间断网测试了一整节课，夹具没出一次问题。他们下课的时候跟我说，原来之前课本上的那些东西，离真实的现场差的不是一点半点。
我觉得这就够了。
