Plan templates

The fourth workflow task determines the necessary object "shape" templates.

A shape template is an object that contains common configuration parameters for derived objects (objects used multiple times within a project). The shape template can now be reused multiple times, either as another template or an object instance. The shape template is derived from a $Master_template object and is designed to represent baseline or "generic" physical objects, and to encapsulate specific, baseline functionality within the production environment. The derived objects are "digital twins" of the physical objects they represent, for example, a valve. In most cases, you can use the $Master_UserDefined object to create the digital twin.

For example, multiple instances of a certain valve type may exist within the production environment. Create a shape valve template that includes the required valve properties.

• Adding an object wizard to the shape template lets you limit the number of required templates through the ability to address a wide range of requirements within a single template. Object wizards allow project developers to select from a list of choices and options contained in a single template to create a variety of derived objects.

If changes are necessary, they are propagated to the derived object instances. Use the drag-and-drop operation within the IDE to create object instances.

The following figure shows multiple instances (Valve001, -002, etc.) derived from a single object template ($Valve):

Application Server is shipped with a number of pre-defined master templates to help you create your application quickly and easily.

The master (base) templates provided with Application Server are summarized in the Base Template Functional Summary. Determine if any of their functionally match the requirements of the devices on your list.

If the base templates do not satisfy the design requirements, create (derive) new shape templates or object instances from the $UserDefined object base template.

A child template derived from a base (parent) template can be highly customized. Add attributes, scripts, and features such as alarm, history, and I/O extensions to the derived templates as needed.

Template derivation

Since templates can be derived from other templates, and child templates can inherit properties of the parents, establish a template hierarchy that defines what is needed before creating other object templates or instances. Always begin with the most basic template for a type of object, then derive more complicated objects. Incorporating object wizards into your template design can help to minimize how many layers of derivation are needed. A basic template hierarchy might consist of the following:

• First layer: corporate template definitions

• Second layer: templates by geographic or areas of operational similarities

• Third layer: plant or local templates

If applicable, lock object attributes at the template level, so that changes cannot be made to those same attributes for any derived objects.

A production facility typically uses many different device models from different manufacturers. For example, a process production environment has a number of flow meters in a facility. A base flow meter template would contain those fields, settings, and so on, that are common to all models used within the facility.

Derive a new template from the base flow meter template for each manufacturer, or alternatively, include options within a single template for each manufacturer (preferred method). The derived template for the specific manufacturer includes additional attributes specific to the manufacturer. A new set of templates would then be derived from the manufacturer-specific template to define specific models of flow meters. Finally, instances would be created from the model-specific template.

Note: For detailed examples of template derivation, see Templates. For more information on templates, template derivation, and object wizards, refer to the Application Server User Guide.

Template containment

In addition to object wizards, template containment allows more complex structures to be modeled as a single object. For example, a new template called "$Tank" is derived from the $UserDefined base or shape template. Use the template to derive other asset objects that represent components of the tank, such as pumps, valves, and levels.

For example, derive two instances from the $UserDefined template called "Inlet" and "Outlet," and configure them as valves. Derive another instance from the $UserDefined template called "Level," and contain all three within the $Tank template.

The containment hierarchy is as follows:

Note: Deeply nested template/container structures can slow the check-in of changes in IDE development and propagation. You can leverage object wizards to limit the template derivation depth.

The preferred method for defining object properties is to create a high-level template and object wizard to define enterprise-wide standards.

• Use template containment to create a higher-level object with lower-level objects. This practice works best when the lower-level object also has many components to it and may contain even lower-level objects.

  However, when adding the lowest-level object to a template, it is possible to use either template containment or attributes. Both allow for an external I/O point link and historization.

  If required attributes (such as complex alarms, setpoints, or other features) are readily available in a template, use template containment. If the lower-level object is very basic, use an attribute. It is always valid to use a contained object, even if it is a simple property.

• Always use a contained object for I/O points and use a user-defined attribute for memory or calculated values. How this is accomplished is up to the application designer, and should be decided in advance for project consistency.

Object wizard best practices

An object wizard can be added to any derived template. However, to maximize the benefits of using object wizards, add your object wizard to the template as close to the top level of the derivation hierarchy as possible. To build an object wizard you must:

• Try to minimize the depth of template derivation by using object wizards. You can provide options that allow subsequent derived objects, either templates or instances, to be easily configured from the choices provided by the wizard. For example, the top level template might encompass corporate standards, while the second level, derived from the corporate standards, can be modified to include specific, local plant requirements.

• Add and configure attributes, symbols, links to external content, and scripts before you build the object wizard.

• An object wizard requires at least one choice group or option.

• Configure choices and options by associating attributes, graphics/content, and scripts. You should limit the number of items associated with each choice or option to avoid configuration mismatches.

• When configuring choices and options, keep the workflow as simple and direct as possible. Remember that users will be working sequentially through the object wizard. If a feature is enabled at one level of the wizard hierarchy, it cannot be disabled at a subsequent level.

  For example, if a symbol has Custom Property "X" enabled and is associated with a choice, do not associate the same symbol with "X" disabled to an option further down in the hierarchy. Instead, leave "X" disabled and override the setting when deriving an instance.

See the Application Server User Guide for additional information about configuring templates and object wizards.

Object template checklist

1. Document which existing templates and object wizards can be used for which objects, and which templates and object wizards need to be created from scratch. For information on a particular object template, see the help file for that object.

2. Design your containment model at the template level before generating large object instance quantities.

3. Create instances from the top "container" template of a hierarchical set of contained templates.

   Such template hierarchies should be tested with one or two instances before proceeding to the generation of numerous instances. Any change by insertion or removal of a contained template in the hierarchy does not result in propagation of new insertions or removals in the instance hierarchies.

   For instances of the containment hierarchy, insertions and removals must be managed individually. However, changes within already included contained templates can be automatically propagated by locking.

   Note: For detailed information about using templates, see Templates.