利用心跳和消息队列进行离散闭合控制

最近做完的一个项目，涉及到实时监控多个设备的状态，以供业务调度处理。

由于每种设备有很多监控信息因素，包括实时运动位置信息、设备启停状态信息、设备通信情况、工作时间、计数器等等，一系列的状态信息，所有的信息因为是无法主动通知回上位机，需要上位机根据协议指令，进行动态拉取。

初始设计时，考虑了两种处理思路：

第一种，考虑利用定时器，定时器发送了设备状态获取指令后，异步线程回调更新全局变量，在定时器的后续处理中，根据变量状态进行逻辑处理，这种处理，在系统中并入设备数量少时，是没问题的，但是当有大量的设备出现，因为各种设备的回调处理周期完全不一样，在时序上开始出现问题了。此时，通过增加各个不同处理的超时屏蔽，来阻隔时序上的混乱，但是这造成了业务调度逻辑的及其复杂，最后在设备扩容时，增加新的设备，出现了牵一发而动全身的问题。

第二种，通过消息队列来处理，在主调度发起时，其对应的回调，作为下一级的调度的消息入口，这个在以前的项目中大量有应用，但是那些项目对设备的监控比较少，基本上是开放式或独立的通信，对设备的旁路参数集信息关心很少。此次因为旁路监控信息增多，再用此处理方式，会把业务主线弄得很模糊。

采用上述两种思路，在项目初期都曾经尝试过使用，第二种在进入编码第二天后放弃了，因为每种设备多达十几个的状态信息监控，势必会造成，十几个回调，这造成了主业务的及其不明朗，代码膨胀和爆炸，已到极限了。

舍弃第二种，采用第一种思路，为了对业务状态进行保持，通过引入状态机，来作为各种状态的保持执行体，效果不错，项目可以进入系统调试阶段了，进入系统调试阶段发现，可能悲剧了，各种设备之间因为状态的高速变化，状态机的不敏感性（超时机制内部），造成了设备闭环控制反馈跑飞了，伺服电机驱动横向前移，出现前后移动，导致底层执行单元的无从下手了，底层有两套运动机构，放在四个伺服控制器上，构成了两组，前后左右移动。分析原因，基于定时器的处理逻辑，执行单元执行中，就会产生迅速的反馈，这会对下一次的扫描周期处理带来问题，不同于PLC控制，项目中因为涉及了大量的数据交互，数据变化锁存，只能靠状态机。因为项目需要上线预演，也就颤颤兢兢部署了。

春节过后，因为项目需要正式上线使用，节前很多功能调试也不是太好，利用假期时间的思考，对整个项目重新梳理和架构，将上述两种思路进行结合，对设备与主业务无关的信息，通过心跳机制，进行状态更新，对需要参与主业务部分的处理，压入消息队列，处理定时器相当于一个大循环，它负责进行驱动，对各种设备周期性的泵入指令，对消息队列也周期性的泵入业务处理指令，状态信息被设备回调处理线程，带回送入状态机，消息队列从状态机中获取关联业务状态判断信息，按照这种思路，原有设计架构被全部推倒，只用了三天左右的时间，就对整个项目重新梳理出来了。所有的设备因为被实时监控起来，其中任何一组设备出现问题，作为备用组的设备就会被实时启用，进行补位，保证了生产场合的高可靠和稳定性。同时因为实时监控设备的运动位置，出现任何对生产安全等有异常的情况，可以实时启停设备，保证人员的安全性。