一个Modbus任务执行结束后，下一个任务应该是什么？

各种各样的多个Modbus设备，每个设备都有各自不相同的任务集，再加上各种动态的实时工艺变化带来的任务数量和次序的随时无规律变化，导致这个问题并不容易回答。

前面讲到的品牌通信任务表，它里面的任务数组，只是个包含本品牌设备的各种工艺可能性的静态任务全集。

这个数组中的任务次序并不能代表它们的实际执行次序，只是存储位置的序号而已。当然有的时候，它们会按照这个次序执行。位置次序代表了默认的先来后到的执行次序。

但更多时候，执行次序会前后或四处乱跳。

这种无规律窜动，既发生在一个设备的任务表之内，也发生在不同设备的任务表之间。

这些规律和跳跃，本质上都源自设备FB实例的界面功能的变化，也就是设备对象中的命令和参数的变化。

外界功能的变化是没有规律的。或者说，至少程序员是不能一厢情愿的指望外界功能变化是有规律的。

因为程序员面对的是这世上所有的各种Modbus设备，这样一个大基准空间。眼前案例只是这个大空间中一个很小的子集。

面对如此复杂的多样性，如何用一种相同的FB设计思想，来包容所有的可能？存在这样一种万能的，能在界面功能和底层IO之间，在任何业务场景下，都能任意来回转换的固定调度方式吗？

很显然，单一固化的调度策略是不可能做到的。

我的答案是：在设备FB内部，采用分层解耦的多层架构来解决这个问题。

这个架构是稳定的。可以通过增减层，或在每一次层中增减元素，把各种可能的调度元素分配到它应该属于的层中去。

程序员的核心是：把过程场景原子化，元素化分解，然后按照场景细节的真相，把这些不同元素各自所需的处理手法，摆放到它们应该去往的层中去。

说到这，可能会意识到：在本质上，这不仅是个编程的问题。它涉及到你如何看待和理解眼前发生的任何事情，甚至如何把你的工作和生活中的事情，分解为纯净的元素，这样的洞察能力。

到最后，这个结构的内容，实际上就是你自身在代码中的投影而已。

这就是观察的本质。