RedundancyMaster特點:
探索這些特點將會改變你對OPC冗余的看法。RedundancyMaster的創新將與你當前的OPC應用程序天衣無縫地一起工作，給你提供了可靠的解決方法。

主/輔機器名
當主OPC Sever 通信不正常時，RedundancyMaster會自動瀏覽會掃描主OPC server和輔 Server。每次當一個新的客戶端連接到底層服務器，應用程序將首先嘗試與運行在主機器上的服務器連接。在此事件中，與主機器的連接失敗或者與主機器的通訊丟失了，RedundancyMaster將嘗試與輔服務器的連接（前提是您已經配置輔OPC server）。依據連接模式，你可以配置應用程序為在可用時自動與主機器建立連接。

連接模式
連接模式定義了怎樣和何時冗余的應用程序連接到優先的主和輔服務器。你運行的模式會影響將故障從一個OPC服務器轉移到其它的服務器的時間。一些模式允許在可用時自動連接到主（服務器）。以下是連接模式的簡介：

Cold（只對于工作中的機器）:
在這種模式下，應用程序同一時間只連接到一個底層服務器。在啟動時，將建立與主服務器的連接且所有相關的客戶端請求都被提交到主服務器。與主服務器的連接失敗或者與主服務器的通訊丟失，發生此類事件時，將會建立與輔助服務器的連接。如果冗余應用程序不能獲得與輔服務器的連接，它將一直在兩個服務器之間“乒乓”直到建立一個成功的連接。

由于在任意給定的時間將只有一個與服務器的連接，Cold連接模式將分配到的系統資源量減到最少。由于不需要在工作中的機器之外另外測試閑置的機器，也減少了網絡流量。這種設置的缺點是要花費時間將故障切換至閑置的服務器。當工作中的服務器發現通信中斷時，應用程序需要建立與閑置的服務器的連接，代表客戶端提交所有的項目，并且啟動相應的callback機制。

Warm :
在這種模式下，應用程序將一直嘗試維持與主輔服務器的連接。只有在主服務器中的項目會被激活和測試。在發生與主服務器的連接失敗或與主服務器的通信中斷事件時，在輔服務器中與主服務器相同的項目將被設為激活。兩個服務器都將周期地被ping，以確定是否連接仍然有效。

由于Warm模式增加了分配的系統資源量。由于就像在Cold模式中運行一樣，周期地ping2個服務器而不只一個，所以網絡流量也有極小的增加。優點是由于冗余應用程序只需要初始化閑置的服務器的callback數據來開始接收數據，故障轉移時間比Cold模式更加減少了。如果你需要最大限度降低應用程序中的數據丟失，同時想要最大限度降低網絡流量，那么你應該使用這種模式。

Hot：
在這種模式下。應用程序將一直嘗試保持與主輔服務器的連接。在啟動時，應用程序將對主輔服務器兩個都初始化數據callback，以使兩個服務器都發送數據變化通知。從主服務器接收到的數據將被轉發給客戶端。在發生與主服務器的連接失敗或與主服務器的通信中斷事件時，輔服務器接收的數據將被立即轉發給客戶端。在人一種情況下，寫入將只被轉發給工作的服務器。兩個服務器將被周期地ping來決定連接是否仍然有效。如果冗余應用程序與任意服務器的通信中斷，將周期地嘗試與故障的服務器重新連接。由于有兩個連接。。。，這種設置增加了分配的系統資源量。由于從兩個底層服務器均接收數據變化通知，且周期地ping兩個服務器來確定他們是否仍然有效，網絡流量上也有所增加。這種設置的好處是察覺到工作服務器的中斷后故障切換立即進行。如果數據的丟失對于你的應用程序非常重要，你應該使用這種連接模式。

OPC服務器的別名:
這個功能允許你用同一個ProgID配置多組OPC服務器。如果在網絡上有多個OPC服務器節點，這個功能可以讓你使用一個OPC服務器供應商。這將允許OPC客戶端通過參考冗余組的aliased ProgID來連接一個指定的冗余組。

根據可用性總是連接到主服務器
當OPC服務器可用時，這個設置使RedundancyMaster自動地將通信返回給主機器。

查詢服務器狀態的時間間隔
這個間隔時間（指定以毫秒為單位）決定了RedundancyMaster多久ping一次底層服務器以確定是否有數據丟失。通過快速的查詢，由于故障檢測更頻繁，可以最大限度地減少故障切換時間。

監測設置:
這個功能允許你配置一定的條件啟動故障切換到閑置服務器。這些條件允許你監測針對指定的服務器項目，以確定底層服務器的正常，因通訊中斷會發生自動的故障切換。