Topic 2.3.1: Project Flow

  • Introduction
    • In order to successfully implement a project for the Wonderware System Platform environment, you should start with careful planning to come up with a working model of your plant or plant area. A six-step project workflow is provided that describes how to complete different tasks in a logical and consistent order, so that you minimize the engineering effort.
    • The project information that you define will become your guide when actually creating your industrial application using the ArchestrA IDE. The better your project plan, the less time it will take to create the application, and with fewer mistakes and rework.

  • Identifying Field Devices and Functional Requirements
    • The first step in project planning is to identify the field devices that you want to include in your application. Field devices include components such as valves, agitators, rakes, pumps, Proportional-Integral-Derivative (PID) controllers, totalizers, and so on. Some devices are made up of more base-level devices. For example, a motor is a device that may be part of an agitator or a pump.
    • After you have identified all of your field devices, you will then need to determine the functionality for each.
    • When identifying field devices, you should start with your piping and instrumentation diagram (P&ID). Typically, this diagram shows all of the field devices and illustrates the flow between them. If you have a good P&ID, the application planning process will take less time and go more smoothly. You should verify that your P&ID is correct and up-to-date before starting the planning process.
  • Defining Naming Conventions
    • The second step in the workflow is to define the naming conventions for templates, instances, and object attributes. Naming conventions should adhere to:
      • Conventions that you use within your company.
      • ArchestrA IDE naming restrictions. 
    • For example, you might have an instance tagname of:
  • Defining The Area Model
    • The third step of the project workflow is to define the Area model. An Area is a logical grouping within your application that represents a portion of the layout of your plant. In a typical manufacturing plant, you would define the following Areas: Receiving Area, Process Area, Packaging Area and Discharge Area. You will need to define and document all of the Areas of your plant that will be part of your application.
    • Each object will need to be assigned to a particular Area. When you install Application Server, a single placeholder is created by default, called "Unassigned." Unless you specify otherwise, all object instances will be assigned to this placeholder location.
    • The following are a few tips for creating Areas:
      • If you create all of your Areas first, you can easily assign an object instance to the correct Area if you set that particular Area as the Default Area; otherwise, you will have to move them out of the unassigned Area later.
      • It is helpful to create a System Area to which you can assign instances of WinPlatform and AppEngine objects. WinPlatform and AppEngine objects are used to support communications for the application, and do not necessarily need to belong to a plant- related Area or any Area for that matter.
      • Alarms will be grouped according to Areas.
      • Areas can be nested.
    • When building an Area hierarchy, keep in mind that the base Area that is assigned to a Platform determines how the underlying objects will be deployed. If a plant area (physical location) is going to contain two computers running AutomationObject Server platforms, then two logical Areas will have to be created for the one physical plant area.
  • Planning Templates
    • A template is an element that contains common configuration parameters for objects that are used multiple times within a project. Templates are instantiated to represent specific objects within the application.
    • For example, you might need multiple instances of a valve within your application, so you would create a valve template that has all of the required properties. This allows you to define once and reuse multiple times. If you change the template, the changes can be propagated to the instances. You can use simple drag-and-drop within the ArchestrA IDE to create instances from templates.
  • Define Security Model
    • Each attribute of an AutomationObject is given a security classification. This provides the ability to define who can write to attributes of an object.
  • Define Deployment Model
    • The Deployment Model view shows which objects instances reside on which computers. In the ArchestrA environment, the physical location of object instances is not required to approximate the real-world environment it models. The Deployment view does not need to reflect your physical plant environment.

Last modified: Saturday, 4 April 2020, 10:03 AM