买来的任何modbus设备，都会带有一张通信参数表。这个表格是该设备在modbus格式空间中的功能界面全集。用户的任何使用需求都是在这个全集之内自由调度。

这意味着几件事：

1、不管是什么Modbus设备，这个表格是共性，而且它的格式可以做成完全通用一致，这代表了一种封装可能。一个UDT可以封装所有种类的设备功能内核，嵌入设备FB。

2、不人为刻意限制和定制锁死用户需求，只要不超出这个全集。这意味设备的功能调度结构必须是开放式的。多种不同的优先级，多种不同的刷新速度和频度。且随工艺的多样化，这些因素一直在变动。所以调度结构必须是组件化的。

比如，想加入一个可以自动检测从站波特率并匹配的功能。这个宏观需求主题，需要被解耦分散到不同的组件中，合成这样一个效果。或者随时我想加入任何一种新增功能，都需要这样解耦。这样的体系才是可以自由扩张和剪裁的，就看自己的项目需求。实践中这样做的效率非常高，不管任何需求，很快就改完。出错率极低，很多时候调试一把直接OK。

3、受设备功能全集的限制，用户的需求交互界面同样可以被封装并组件化。

当用户交互界面、从站功能界面，Modbus通道执行单元，这三者被组件式调度结构整合到一起，就形成了一个可以适用于所有Modbus设备，所有的需求变化，从界面到底层通信的完整架构。在此架构下可以轻易把一个现有FB移植成其它modbus设备。实践证明了这点。

视野放远一些，这种结构远不仅是给Modbus准备的。用组件化观点，站在多变的用户需求角度来审视FB，会重新理解编程中所指的一个设备到底是什么意思。