读一套测控系统的分工时，最让我安心的一个设计是它把算和动分得很开。上位机在工控机上算，测一圈信号、判断零件弯没弯、下一刀压多少；下位机在设备边动，伺服转、压头下、支撑托。
我以前写这类东西，容易一股脑全塞进上位机。反正都能调，干脆上位机把动作时序也一起发了，下位机当个传声筒。看起来效率高，少一层通信，少一套协议，上位机点一下设备就动，简单粗暴，也好调试，至少在我自己的开发机上。
但我忽略了一件事：上位机跑的是 Windows，有线程调度、有 GC、有界面卡顿，这些不确定性对算无所谓，对动要命。
真正让我改观的是安全那一侧。那套系统的安全联锁，限位、急停、互锁，全在下位机本地自成回路。也就是说，哪怕上位机整个崩了、通信线断了，设备也不会因为没收到上位机的停而继续危险动作。
还有一个细节：零件合格还是不合格，是上位机算出来的，但把合格的放这边、不合格的放那边这个分拣动作，是下位机自己执行的。上位机只把合格不合格这个结果递过去，具体怎么动下位机自己编排。上位机是法官，下位机是法警，法官只下判决，不亲自上手。
边界划清楚，比谁更聪明更重要。把判断留在灵活但不确定的那一层，方便迭代算法；把动作放在确定且保命的那一层，实时、安全；两边各司其职，谁崩溃都不连累另一边的核心职责。反过来，如果你把动作时序也交给上位机，等于把设备安不安全绑在了 Windows 今天卡不卡上，那不是聪明，是赌。
后来我不管写什么系统，都先画一条线：哪边不确定，哪边要保命。判断留在灵活那层，动作交给确定那层，这条线画对了系统就稳，画反了你天天在给不确定性擦屁股。