How to Setup multiple Intelli-Site Servers to Communicate with Each Other
Author: Lori Tassin Reference Number: AA-00346 Views: 31995 Created: 04-02-2013 09:26 AM Last Updated: 08-09-2013 04:44 PM 0 Rating/ Voters

 View products to which this article applies.

Introduction

Intelli-Site Enterprise Operations is a mechanism that allows Servers or redundant Server pairs to communicate with each other through a remote link.  This allows companies and organizations with multiple facilities to share vital information but each facility functions independently.  Through Enterprise, access control can be centralized and organization-wide.  Reports can provide information for the whole organization.  And key systems can be monitored and if their Server fails, be taken over by the central Server.

Enterprise Operations is well suited for school districts,  universities, office buildings, corporations, airports and sea ports, and any organization with multiple facilities.

Enterprise Operations is available in both Intelli-Site GS and Intelli-Site ES.

Procedure

Before we get into the details of setting up Enterprise, lets 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 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 check boxes are pretty self-explanatory.  Check "Send Card Updates to Remote Server" if cards that are added or updated on the 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 the 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 <Add Row> 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

How to set up Enterprise Operations:

Fully program the Projects on each Server including the the RTUs and Virtual Points that will be shared.

The Access Sets that will be assigned by another Server must begin with a prefix that will be specified when setting up the Enterprise link on the remote Server.

The RTUs that are controlled by another Server must be "virtualized" on the local Server.  

    • Right-click on the RTU and select "Properties..."  The Properties dialog for this RTU is displayed.  
    • The "Virtual Point:" checkbox can be found in the RTU Setup group on all RTUs except Virtual Inputs and Outputs.  

      Click the checkbox.  You may also drag a virtual point into the orange field.  The Server will set this point when the RTU is virtual and clear it when the RTU is not.  This allows you to programmatically monitor the state of the RTU.

Create a network share for the message buffers

 Like all shares for Intelli-Site, this share must grant read/write privileges to all that can access it.  Read/Write is also known as Full Control.  This can be a unique share, or the same share used for remote Workstations.  See the following articles on setting up network shares in Windows:

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.  

Install and configure the Enterprise RTUs

If you did not install the Enterprise driver, run the Intelli-Site Installer.  When asked if you want to install any drivers, click yes.  Locate the Enterprise driver in the list and click on the checkbox.  Then continue the install.  When the install is complete run the Server, the DriverService, and the Workstation.  Logon to the Workstation.

  • In Design Mode, add an Enterprise RTU for each of the links this Server will have with other Servers. 
  • Right-click on the Enterprise RTU and select "Properties...".  The Properties dialog displays. 
    •  Each Enterprise RTU should be in a different Domain since there has to be a different driver per link.  
    • Use the <Browse> button to find and select the appropriate share for the Message Buffer.
    • Specify the prefix that is on all Access Sets for the remote Server.
    • Drag and drop into the Translations table the RTUs that are shared between the local Server and this remote Server. Click <Add Row> as needed.  If the RTU to share is a local Virtual Inputs or Virtual Outputs RTU, click the "Local" check box.  On the remote Server, leave the "Local" checkbox clear.  It should only be checked on one Server.

                                            (A fully configured Enterprise RTU)

Install and Configure the Enterprise Driver

With the Enterprise RTU configured, now let's turn our attention to the Enterprise driver itself.  The Enterprise drivers communicate to each other via TCP/IP.  Generally speaking, Intelli-Site drivers initiate communication with devices that are "listening" for a connection request.  In the case of the Enterprise driver, the device is another Enterprise driver.  Therefore, one of these Enterprise drivers needs to be configured as a listener. 

  • Open the DriverService by right-clicking on the  icon in the System Tray.  Select "Open".
  • Click the <Add> button. Select the "Enterprise" driver.
  • In the Choose Communication Type dialog, select either "TCP/IP - Network Communications" or "TCP/IP Listener - Network Communications".  Remember that the other end of the Enterprise link needs to be the type not selected.
  • Give the Enterprise driver a name that is meaning to you so you will be able to differentiate it from other Enterprise drivers.  In our example, we named it "RemoteSite1 Link".
  • Click on the "Driver" tab.  Enter the correct Domain and Net.  This is the Domain and Net from the Enterprise RTU that corresponds to this driver.
  • Click on the "TCP/IP" tab.  Add the IP address or hostname of the remote Server computer.
  • Click <OK>

The Enterprise driver is configured and ready to be brought online.

Repeat for every Server.

Products

APPLIES TO
  • Intelli-Site CS v.<N/A>
  • Intelli-Site ES  v.3.9
  • Intelli-Site GS v.3.9
  • MASC v.<N/A>
  • Compass6E v.<N/A>
  • Compass Hardware 
  • MAC Hardware


Copyright © 2013 OSSI, LLC.  All rights 

reserved.

Intelli-Site® 

is registered in U.S. Patent & 

Trademark Office. 

All other registered and unregistered 

trademarks are the sole property of their 

respective owners.

goto Top

Quick Jump Menu