Procedure

Before we get into the details of setting up Enterprise, let's consider the following example.

In this example, Remote Site 1 and Remote Site 2 are independent sites with their own Servers and Drivers controlling their field devices.  Central Control wishes to have access to live information and limited control of the field devices at both of the remote sites.  Understand that the field devices have a single communications interface that the Servers and Drivers at the remote sites are using which makes it impossible for the Server at Central Control to connect to them at the same time.  Therefore, Central Control and the remote sites will use their Enterprise links to transfer information to each other.  The remote sites will send live update information to Central Control and Central Control will send requests to the remote sites that will be forwarded to the field devices.

Each of the sites in an Enterprise system will have its own Project file and programming.  The Central Control site will have its own programming as well as virtual copies of the remote sites' RTUs that it will want to control or from which it will want to receive information.  Each site will have Enterprise drivers linking them together as necessary.  Therefore, the importance of planning cannot be stressed enough.  Plan where all of the field devices will be, which Servers will be able to control them, which Servers will take over if the owner Server goes offline, where will card management occur, and by whom.  Consider reporting.  What reports will be generated where and what comprehensive reports will be needed?

To aid in this planning, let's discuss the Enterprise driver and its setup.  

The Enterprise Driver

The component of the system that sends messages between Servers is the Enterprise driver.  Each Server will have an Enterprise driver for any Server with which it will want to communicate. When the link is up, messages will be transferred.  When the link is down, those messages will be buffered on disk until the link comes back online.  The buffered messages will then be sent through the link.  In the example above, there is an Enterprise link between Central Control and Remote Site 1 and Central Control and Remote Site 2.  Therefore, there will be one Enterprise driver on Remote Site 1, one Enterprise driver on Remote Site 2, and two Enterprise drivers on Central Control: one for its link to Remote Site 1 and the other for the link to Remote Site 2.

Below is the "Properties..." dialog for the Enterprise RTU that links the Central Control system with RemoteSite1. It's like any other RTU in the Project in that it has a Domain/Net/Node that works just like the Domain/Net/Node for most RTUs.  There are three sections unique to the Enterprise RTU: "Message Buffer File:", "Card Management Settings", and "Translations".

Message Buffer File

There will be times that messages between Servers will have to be buffered.  For whatever reason the link between the two Servers is offline or non-existent.  To keep from losing any messages, they will be written to a buffer file until the link is online.  The buffer file is written to the share specified in the "Message Buffer File:" field.  This share, like all shares for Intelli-Site, must grant read/write privileges to all that can access it.  Read/Write is also known as Full Control.

NOTE: If Server Redundancy is enabled, this share should be on a third system so that all of the buffered messages will be available even if the Master Server switches while there are messages in the buffer.  

Card Management Settings

If cards will be managed at the central control site and used at the remote site, this is where the necessary settings are.  There are three settings: two checkboxes related to sending card data to the remote Server and a field related to Access Sets.

The two checkboxes are pretty self-explanatory.  Check "Send Card Updates to Remote Server" if cards that are added or updated on this Server should be sent to the remote Server.  Check "Send Card Image Updates to Remote Server" if the image associated with a card should be sent.  Images are large files and take up a lot of bandwidth.  If it's not important to have them at remote sites, don't send them. 

It is important to limit the amount of traffic between the two Servers to only the necessary information.  Just because a card has been updated doesn't mean it is destined for the remote Server.  Only cards that have Access Sets associated with the remote Server are sent.  How does the local Server know which access sets are related to which Server? The "Remote Access Set Name Prefix:" field.  All access sets associated with this remote Server will begin with the prefix specified.  In the example, the prefix is "[NE]".  The prefix can be any printable character.  The names of the access sets must match exactly on both ends including the prefix.  An example access set name would be [NE]Main Entrance.  It would be defined on both Servers.  

Translations

There may be RTUs on the remote Server that the local Server will want to know about or even communicate with and vice versa, a kind of sharing if you will.  This is where the mappings and translations are defined.  And this is where control of these RTU is declared.

All RTUs that a Server will want to know about or communicate with must be defined on the local Sever even if it really is controlled by another Server.  Intelli-Site will share the data from these shared RTUs using the Enterprise driver.  Therefore, the Enterprise driver needs to know which RTUs are shared and which Server is in control of these RTUs.  The RTU is defined to be Local to a Server if that Server is in control of it.  

To define the mapping, drag and drop the RTU into the orange RTU field.  If there is more than one shared RTU, click the button to add rows to the translations table. It will populate the Domain/Net/Node with the Domain/Net/Node of this RTU as it is defined in the local Project.  It may or may not be the same as the Domain/Net/Node on the remote Server. The number of possible Domains is 65535.  There are enough Domains available to prevent the need to translate, but again this requires careful planning that encompasses all of the Intelli-Site Servers involved in the Enterprise Operations. Even with careful planning, there may be situations that require duplicate Domains on different Servers making translation necessary.  Map those translations here.

There are two ways to specify the controller of an RTU.  One is with the"Local" checkbox and the other is using the "Virtual" property of the RTU.  The "Local" check box is for Virtual Points because there isn't a "Virtual" property on a Virtual Point.  For all other RTUs, the "Virtual" property is what Intelli-Site uses to tell if the RTU is local or remote.  This allows the controller to be decided programmatically so the control of the RTU can be taken over by one or the other Server depending on circumstances.  If the RTU is virtual, then the local Server is not the controller.

We are now ready to set up Enterprise Operations.  There are a few easy steps.

1. Fully program the Projects on each Server including the RTUs and Virtual Points that will be shared.
2. Create a network share for the message buffers.
3. Install and configure the Enterprise RTUs on all of the Servers
4. Install and configure the Enterprise Drivers