在物联网的软硬件系统中，常会有更新和查询硬件状态的场景。
类似系统中，普遍的流程为：用户触发系统发送指令（查询状态）--硬件接收指令--硬件更改状态--硬件返回指令--系统接收指令--展示给用户最新状态。一般情况下，我们会将系统发送指令（接口1），等待硬件完成状态更新后，将会发送查询状态结果的指令（接口2），此时用户界面再发送请求（接口3：一般为间隔一定时间轮训查询）。
另外，考虑到系统中可能有很多入口可以触发这个查询最新状态，基本的流程都如上述所示。可能会有多个指令同时发送到硬件：
A--发送指令（T1）--硬件--系统更新状态（T2）
B--发送指令（T3）--硬件--系统更新状态（T4）
A--查询界面（T5）
B--查询界面（T6）
假如我们的发送指令与查询状态必须一一对应的话，那么T3，T4与T6必须是阻塞的，或者系统更新状态时必须带上这次查询的版本号。这样一来查询展示必须是串行，或者我们必须存储不同查询版本对应的查询结果。
但是考虑到状态是一个通用的数据，即A查询到了状态，只要是硬件更新状态也是大于B查询的时间，那么A查询到的状态对于B也是可用的。所以字段设计时，我们可以使用statusLastUpdateTime字段作为状态的版本。
即假设T1与T3几乎是同时发出指令，系统更新状态发生在晚一些的T2和T4时刻，那么无论T2和T4时刻的状态何时传回到系统，只要查询到状态更新时刻（T2或T4）大于指令发出的时刻，这个状态对于A和B都是可用的，如果状态更新时刻小于指令发送时刻，那么该状态即不可用，客户端需要一定的处理，让用户继续等待或者再次发送查询指令。
当初考虑此处的设计时，总是想着状态的指令发送与状态的查询必须一一对应，但是这里提醒了我，对于通用状态，或者其它的变量，只要是通用的变量或者字段，都可以采用类似的模型，只需要一个字段，就能解决状态展示的问题。
另外，对于查询界面的轮训策略，我们需要先看指令发送到系统状态更新的时间平均是T，我们设置第一次查询这个指令的时间就可以在T的基础上进行短暂的延时即可。比如T为2S，那么我们查询的第一次可以设置为发送指令的2.5S之后，一般情况下，这个时间就能查询到最新的状态。