• Introduction

• Device Integration (DI) Objects represent the application's network and devices, and mirror the actual device hierarchy. In Application Server, Device Integration (DI) Objects are a subset of Automation Objects available in the Template Toolset of the ArchestrA IDE. As a subset of these Automation Objects, Device Integration Objects consist of two parts:
• DI Network Object, which represents the communications port and are thus associated with DA Servers.
• DI Device Object, which represents the physical devices that make up a network. Examples of DI Device Objects are network bridge devices or PLCs. When the objects are deployed, they represent the network hierarchy. Each level of this hierarchy can be monitored for its individual status.

• Device Integration objects are used to represent communications channels and field controllers. As such, they are most often arranged in a hierarchy that models the physical hierarchy of the network and devices on that network.
• Device Integration objects are designed to make it very easy to integrate DAServers into the ArchestrA environment.
• Therefore, deploying a DI Network actually deploys the DAServer and its associated components within the ArchestrA IDE/Galaxy. This facilitates the DAServer installation process for end-users.
• Several DI Objects are delivered and installed by default with your Application Server software. There are also several DI objects available that are for specific DA Servers. These are available on the Wonderware Device Integration DVD.

• DI Object Advantages

• Device Integration Objects (DI Objects) represent communication with external devices. DI Objects may be DINetwork Objects (for example, the Redundant DI Object) or DI Device Objects. DI Objects (and their associated AppEngine) can reside on any I/O, DA, or Automation Object Server node in the Galaxy. DI Objects allow connectivity to data sources such as DDE servers, SuiteLink servers, OPC servers, and existing InTouch applications.

• The advantages of using DI Objects are as follows:

• DI objects allow you to configure, deploy, and monitor DAServers from one centralized location.
• DI Objects can be used to represent all devices and PLCs in a network, enabling representation of an entire plant, including a hierarchical view of network connectivity.
• DI objects are so closely tied to the DAServer that when an object is deployed across the network, it remotely installs the DAServer (This means that you can install the DAServer without going to the actual machine, and that the DAServer connects immediately.).
• DI objects are very closely tied to the DAServer they are assigned to, so that when an object is deployed, it brings with it all code, including registry, scripting, attributes, and parent.
• Scan On Demand
• Advanced Communication Management minimizes network traffic and CPU usage of a DIObject or DAServer. While the client application is running, scanning for an attribute value is suspended when the owning object no longer appears in the running application. For example, Advanced Communication Management suspends scanning for an object's attribute value when the operator minimizes the application window containing the object. When the operator shows the window containing the object again, Advanced Communication Management resumes scanning and the object's attribute value is updated in the application.
• Scanning can be configured using the following options:

• Active
  

• Items are deleted and added to the scan group as requested (referenced) by the clients.
• Items that exist when a scan mode change occurs are not deleted unless the previous mode was ActiveAll and the items are no longer referenced.
• The Active scan mode polls all points that are referenced, whether active or inactive.
• In Active scan mode an attribute is always in the active state. When the last reference to the attribute is unregistered/unadvised, the attribute is deleted.

• ActiveAll

• Scanning is continuous and dynamic attributes are never removed when unsubscribed.
• Items are activated by client requests, but continue to exist even after the client are not interested in them anymore.
• Items are not removed when the scan mode changes.
• The scan group polls the field device for all points irrespective of whether they are currently active, inactive, or even subscribed to by items.

• ActiveOnDemand
  

• When the scan mode is configured as ActiveOnDemand, attributes that are not actively being referenced by any client or object are made Inactive and are not scanned.
• New Items are deleted and added to the scan group as requested (referenced) by clients.
• Items that exist when a scan mode change occurs are not deleted unless the previous mode was ActiveAll and the items are no longer referenced.
• ActiveOnDemand scan mode polls the field device for currently active items only. Inactive items are not scanned.