Download Installing SQL on NT Workstation

RSSql Redundancy
Using Process Logix
Objectives: To establish a RSSql configuration communicating to standalone* Process Logix
(PLX) controllers with redundant OPC servers logging mission critical data to tables contained
within a remote SQL Server computer and database. This configuration will avoid duplication of
data within the table and only RSSql transactions with valid data will be logging into the database
at any given time. This configuration is strictly for a historical data logging application. Should
components of the system malfunction or become disconnected, the logging of data will continue.
The diagram below displays the hardware/software configuration used for the application.
RSSQL Handshaking
Configuration: In order to have only valid RSSql transactions logging data to the SQL database
and avoid duplicate records a handshaking method is used in conjunction with the PLX controller.
The handshaking is accomplished by using the ‘Transaction Stores Data on True Expression’ in
RSSql as well as a ‘numeric block’ storing a hard coded value in the PLX. Using the
Configuration\Check List… is an easy method for checking configuration setups within RSSql.
1) In this configuration, the PLX’s were polled via OPC every 5 seconds for the data to be
logged (50 points in each PLX + the numeric block for a total of 102 points). This created a
total of four (4) transaction configurations (one for each PLX through each OPC server)**.
Two separate sets of Data Points are configured since there are 2 possible OPC servers. In
the case where the ‘primary’ OPC server fails and the ‘secondary’ server becomes active the
‘redundant set’ of RSSql transactions will become valid and log to the database. Each
Transaction will poll for the information, but through the trigger expression, only the
transaction with valid data is logging to the SQL Server database.
2) Each RSSql transaction needs the Transaction Stores Data On True Expression configured
within the Trigger And Storage Parameters screen. Example: The transaction configured to
log from PLX-1 through OPC ServerA would have PLX_OPC.o_0.quality1.numeric.pv ==55.
In this example PLX_OPC.o_0.quality1.numeric.pv is simply a constant value stored in a
numeric block within the PLX (for multiple PLX’s create a unique point in each)**.
3) An additional option is to create a data object and column in the database that will store a
value that is unique to each transaction. For example, the ‘PLX1SVRA’ transaction will log
the word “PLX1SVRA” and the transaction for logging data from PLX-2 through Server B
would put “PLX2SVRB” into the column when active. This provides a method to know from
which controller and through which server the data came from.
4) Should the connection to the database be lost, the data will be cached locally at the RSSql
logging station until a database connection is established.
5) Repeat this same type of configuration/process for each standalone PLX in the application.
Conclusion: The configuration offered in this application provides a robust methodology to meet
all objectives of a mission critical logging application. The configuration provides for double
jeopardy situations where a PLX controller, OPC Server, and the SQL Server malfunction. In
testing, the logging of 102 datapoints every 5 seconds did not have any adverse effects on the
performance of the PLX database synchronization. If the ‘primary’ server fails over then RSSql
will still log data from all controllers through the ‘secondary’ server. This architecture is needed
until the Process Logix product releases an OPC client that automatically communicates to the
valid/primary OPC server (this is expected to be released in the second half of 2001)
* Although this architecture does not directly account for redundancy of the PLX controllers, the
configuration would follow the same design.
** With this configuration, if a PLX controller drops off then RSSql will still successfully log data
from the other PLX’s through the primary server, when the failed PLX is back online RSSql will
resume logging. In order to avoid NULL values being logged to the database, it is recommended
to create a unique transaction in RSSql for each PLX controller and log the data to a unique table
within the database that contains columns for only those data points. If this is not a concern, then
the application can be simplified by creating just 2 RSSql transactions (one for each server) that
simply monitor one data point for the constant/valid value that could exist in any one of the PLX’s.
The transactions in this example were configured as follows:
PLX1SVRA will log timers 1-50 from PLX1 controller through Server A, when data is valid
PLX2SVRA will log timers 101-150 from PLX2 controller through Server A, when data is valid
PLX1SVRB will log timers 1-50 from PLX1 controller through Server B, when data is valid
PLX1SVRB will log timers 101-150 from PLX2 controller through Server B, when data is valid