Identify field devices and functional requirements

The first project workflow task identifies field devices that are included in the system. Field devices include components such as valves, agitators, rakes, pumps, Proportional-Integral-Derivative (PID) controllers, totalizers, and so on. Some field devices consist of more than one base-level device. For example, a motor may be a component of an agitator or a pump.

After identifying all field devices, determine the functionality for each.

Field Devices Checklist

1. The Piping and Instrumentation Diagram (P&ID) below is shown as example for identifying field devices. This diagram shows all field devices and illustrates the flow between them.

   A good P&ID can make the application planning process faster and more efficient. Verify that the P&ID is correct and up-to-date before beginning the planning process.

   The following P&ID example diagram shows the equipment used in the pre-treatment process for a wastewater plant that consists of four separate areas.

   

   Each of the four areas in the PI&D example are shown in greater detail below.

   

   

   

   

2. Examine each component in the P&ID and identify each basic device. For example, a valve can be a basic device. A motor, however, may consist of multiple basic devices.

3. Once a complete list is created, group the devices according to type, such as valves, pumps, and so on. Consolidate any duplicate devices into common types so that only a list of unique basic devices remains, and then document them in the project planning worksheet.

Each basic device is represented in the System Platform IDE as an AutomationObject. An instance of an object must be derived from a defined template. The number of device types in the final list will help determine how many object templates are necessary for your application. Object wizards can allow a single object templates to derive many different types of instances. For example, a wizard for valves can let you derive instances that represent 2-way, 3-way, 4-way valve, right-angle, and other valve types, from a single template. Similarly, a wizard for motors can be used to select between fixed and variable speed drives, as well to select other features.

Group multiple basic objects to create more complex objects (containment).

For more information on objects, templates, object wizards, and containment, see the Application Server User Guide.

Functional requirements checklist

Define the functional requirements for each unique device. The functional requirements list includes:

• Attributes: Determine the attributes needed to define the object. Attributes are parameters of the object that can access data from other objects as well as provide access to their own data to other objects (inputs and outputs).

• Scripting: What scripts will be associated with the device? Specify scripts both for self-configuring the object as well as for run-time operation.

• Historization: Are there process values associated with this device that you want to historize? How often do you want to store the values? Do you want to add change limits for historization?

• Alarms and Events: Which attributes require alarms? What values do you want to be logged as events?

• Security: Which users will access to the device? What type of access is appropriate? For example, you may grant a group of operators read-only access for a device, but allow read-write access for an administrator. You can set up different security for each attribute of a device.

All the above functional requirement areas are discussed in detail in this Deployment Guide.