Typically, you want a module to perform one main function. This way, you know which modules to work on and what impact changing them has when you are troubleshooting or maintaining your system.
Modules can be downloaded and modified independently from other modules. A module's execution can be stopped or debugged without affecting other modules. Because of this modularity, it makes sense to define your modules so that they contain one functional piece of your system. This enables you to operate, debug, download, and take out of service a single module without affecting other modules. Generally define control modules for one or more field devices and their related control logic.
If modules are very large and have multiple functions, it is difficult to troubleshoot and maintain the system and isolate problems and areas for modification. Also, the diagrams for the algorithm get very large and harder to maintain. Conversely, using several small modules to perform a single control task makes it harder to troubleshoot (one module at a time). Smaller modules require that the operators know several module tags to operate a single control device. You must also read and write many external parameters in order to define the module-to-module communications and transfer the information to other modules.
Ultimately, you must determine how your system and its functions should be logically divided into modules. However, if you find that a module is getting large and complex, you might want to look for ways to divide it up logically; conversely, if you are defining a large number of external parameters to transfer data between modules, consider containing smaller modules within a larger control module or equipment module.
The following figure shows a simple tank-level example and how it might be logically segmented into three control modules. The control modules are circled. If these three modules require coordination, the three control modules shown could be contained within a single equipment module.
