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 validPLX2SVRA will log timers 101-150 from PLX2 controller through Server A, when data is validPLX1SVRB will log timers 1-50 from PLX1 controller through Server B, when data is validPLX1SVRB will log timers 101-150 from PLX2 controller through Server B, when data is valid