The DeltaV system enables you to create and maintain control strategies in small, modular components. These components are unique, named (tagged) control entities called modules. The concept of the module is fundamental to the DeltaV system. The module is the main building block for a system. Modules link the algorithms, displays, I/O, conditions, and other characteristics to the equipment. Depending on its type, a module can be composed of parameters, a history collection strategy, alarms, conditions, algorithms, and display elements. These items are bundled together logically as modules so that you can use them in your control strategy.
The following figure represents a module and some of its possible components.
Module Component Chart
DeltaV modules enable you to define control strategies and equipment control that match your plant and operating philosophy. You match the DeltaV control system to your application rather than forcing your application to comply to a rigid, predefined control system structure.
The DeltaV system supports the S-88.01 definitions of hierarchy and modular approach to configuration development. This standard provides a good structure for control development, while still allowing you to define modules that are specific to your process. The DeltaV system provides the control module, equipment module, and area functions defined by S-88.01.
Note The order of the modules in the DeltaV Explorer tree does not imply any execution order in the controller.
Control modules and equipment modules can execute separately or may be contained other modules with some restrictions. Control modules typically provide control for a single control element such as a valve. Equipment modules typically provide supervisory control for a collection of control modules and other equipment modules that are contained inside the main equipment modules. The algorithm for the containing equipment module manages the operation of the contained modules. Another type of hierarchy exists when control modules are contained within other control modules. However, note that control modules cannot contain equipment modules. Modules can be contained within other modules four-deep. Circular references are possible, but this is typically not a good engineering practice.
Equipment modules interface to the module-level parameters of the control modules that they contain. The user defines the control module interface to the equipment module by elevating key control module parameters to the module level by using input parameters. These well-defined interfaces support good engineering practice for debugging and configuration. Access to the contained control module is simplified and the underlying algorithm is protected. This also makes it possible to substitute one contained module for another, provided the input parameters are of the same names and types.
Use equipment modules for coordinating the operation of multiple modules that need to work together to control related equipment.
Refer to Equipment Module Example to see an application of this module type.
Modules use an underlying algorithm for their essential functions. You select the algorithm type based on control requirements. Module Algorithm Types introduces these Types.
Your application may require many modules that are similar or identical. The DeltaV System provides several features that reduce engineering time, promote reuse of engineering work, and minimize the maintenance required for modules.
Two key features for reducing engineering and maintenance time of your control strategies are module classes and module templates. Module classes are modules that you define. They define components (parameters, a history collection strategy, alarms, conditions, and algorithms) for a group of similar modules. Modules based on a class are referred to as instances or class-based modules. The module class remains linked with its instances so that, in general, changes to the module class propagate to the instances. Module templates are fully-configured modules that can be modified to fit your control needs. The DeltaV System ships with several module templates. You can also create your own module templates. Module templates can be based on module classes as described in the Module Classes topic.
Understanding these features and using them together helps you significantly reduce engineering time and upkeep on your modules. Refer to the topics Module Classes and Module Templates for more information.
Users can specify history collection for the module through the DeltaV Explorer or Control Studio. History collection can be enabled for any of the parameter fields within the module. History collection enables the continuous historians in the DeltaV system to capture and store the field values over time. You can retrieve these values through the Process History View.
If you copy a module that includes history collection, the collection
functions are retained. Refer to the Configuring
History Collection topic for more information.
The priority of a module is associated with the scan rate as defined in the following table.
Module Scan Rate |
Priority |
| 100 ms, 200 ms | high |
| 500 ms, 1 s, 2 s | medium |
| 5 s or greater | low |
Modules can communicate directly with each other, and can be coordinated by other modules to perform higher-level control strategies.
All module communications and coordination are done by referencing the module's unique tag name (for example, FIC-101). Communication with the module is done by tag reference throughout the DeltaV system, even when the module is communicating with another module in another controller or with an operator display.
Module blocks allow one control module to be represented on the diagram of a different control module. This allows the interactions between multiple control strategies to be visually created and maintained while ensuring the isolation and integrity of each independent module. The module block is graphically wired to other blocks on the strategy. The following figure shows a module block called MODULE with an output parameter that is wired to a splitter function block. Note that you cannot nest module blocks. For more information on module blocks refer to Module Classes.
Module Block Wired to a Splitter Function Block
The wires connected to the module automatically establish communications between the two modules during run time. Any parameter within the referenced module can be wired.
You can also insert a composite into a module. Composite blocks are user-defined blocks that represent a group of function blocks or Sequential Function Chart (SFC) steps. Composite block execution is synchronous with other function blocks in the module.
Composite blocks can be linked or embedded. The main differences between linking and embedding blocks are in storing the algorithm data and updating the data after the block is created. When you link to a composite block, it remains linked to the library composite template it was created from. The system updates the linked block when you modify the structure of the original template. Linked data is stored in the source block; the linked block stores the location of the source block and displays a representation of its template. The parameters in a linked block can be unique for that block.
When you embed a block, the block does not change if you modify the source block. Embedded blocks become separate, standalone blocks. You can edit the structure of an embedded block, and the original composite block remains unchanged.
The modular approach to configuration makes troubleshooting easier and reuse of the modules possible. This approach also avoids the complications of creating one large program to perform the control strategies for each controller and the difficulty of defining and accessing the control data based on the physical location.
Sometimes implementing a control strategy in a composite block works as well as it would in a module. Some of the factors that determine whether you should use a module or a composite block include:
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.
Example of Modular Tank-level Control
When naming a module, you must follow these rules:
Note The Continuous Historian cannot collect data on parameters for nodes or modules that begin with a dash (-), dollar sign ($), or an underscore followed by a dollar sign (_$). Process History view reports that data is unavailable for parameters from nodes or modules that begin with these characters.
Note When referring to module names and associated paths always use uppercase letters.