Define the area model

The third workflow task defines the area model. The Model View in the IDE shows the Galaxy organized by area object.

An area represents a logical grouping of objects within the physical plant layout. For example, Receiving Area, Process Area, Packaging Area and Dispatch Areas are all logical representations of a physical plant area. In the previous example shown under Identify field devices and functional requirements, the areas are Lifting, Screening, Grease and Sand Removal, and Primary Clarifier. Alarms originating from an object in an area are aggregated to the area object.

Define and document all necessary plant areas to ensure each object is assigned to its relevant area.

Note: The default installation creates an Unassigned area. All object instances are assigned to this area unless a different area is designated as the default.

Area model checklist

1. Using the Model view of the IDE, create all areas first. An object instance can then be easily assigned to the correct area; otherwise, you will have to move them out of the unassigned area later.

2. Create a System Area. Assign instances of WinPlatform and AppEngine objects to the System Area. WinPlatform and AppEngine objects are used to support communications for the application, and are not necessarily relevant to a plant-related area.

   Area and application objects (such as the UserDefined object) are independent of the physical environment that they represent. Therefore, these objects can be moved easily between a development galaxy and a production galaxy.

   Platform and engine system objects, and device integration (DI) client objects, which link to PLCs or RTUs, link directly with the physical plant/environment. These environment-dependent system and DI client objects are not transportable between different physical environments.

3. Areas can be nested. Sub-areas can be assigned to a different AppEngine on a different platform. Note that while area objects host application objects, the objects assigned to one area object cannot scan across multiple AppEngines.

4. It may be practical to create an object instance for one area at a time. If using this development approach, mark the area as Default, so that each object instance is automatically assigned to the Default area. Before creating instances in another area, change the default setting to the new area.

5. Equate various areas to Alarm Groups. Alarm displays can easily be filtered at the area level.

Note that areas and the application objects that they host are not environment-dependent, and thus can easily be moved between a development galaxy and a production galaxy. System objects such as platforms, engines, and Device Integration client objects are, in contrast, linked to the physical infrastructure, and cannot be easily moved because they have been configured to communicate with a specific machine name or IP address, or in the case of DI client objects, with a particular PLC. Therefore, we recommend that you create an infrastructure specific to the environment in which you are operating. A development environment should have its own infrastructure. Similarly, if you have a separate test environment, it should also have its own infrastructure. Your production environment should have its own infrastructure as well. You can export the area objects and the application objects that they host and move the objects between environments as needed.

For more information on areas, see the Application Server User Guide.