Redundanc．ｍａｓｔｅｒOPC冗余軟件

RedundancyMaster
通過允許多個OPC服務器配置為(redundancy pairs)冗余組來增強OPC數據的可靠性和可用性。每個冗余組對于任何OPC客戶端都作為單獨的OPC服務器無縫地顯示。

RedundancyMaster可以添加到一個服務器/客戶端的應用程序而不需要對該應用程序重新配置，以保持你的過程一直運行而沒有故障時間。

Redundanc．ｍａｓｔｅｒ手冊 (PDF)
Redundanc．ｍａｓｔｅｒ產品彩頁 (PDF)

在工業領域里可靠性
OPC DA技術已經證明了其可靠地用于實際中要求一致的數據訪問設備和系統的各種可能情況。但是，有一些其它的因素會危及到系統的集成性，一些是軟件、硬件、甚至人為因素。通過使用OPC Redundancy技術可以使這些系統更加可靠和有效。

增加RIO（投資回報率）& 減少系統故障時間
為了滿足增加系統可靠性的需要，kepware開發了RedundancyMaster。 RedundancyMaster位于OPC客戶端機器，通過hooking into（介入）OPC客戶端和服務器之間的OPC calls，使系統網絡上的主、輔OPC服務器的連接更容易。如果由于某些原因OPC客戶端與主OPC服務器失去通信鏈路或者遇到一個使用者指定的環境（例如：一個項目不能接收更新，遇到一個指定的項目值，或者一個項目的質量設定為差）RedundancyMaster將放棄網絡中的主OPC而提升輔OPC服務器——減少系統故障時間并且節省資金。

使用簡單
RedundancyMaster是一個無縫的應用程序而不需要對OPC客戶端和服務器的應用程序做任何改動。你只需要幾分鐘就可以直觀地配置且讓你無需頭痛地運行一個冗余的OPC系統。只需簡單地瀏覽和選擇主輔OPC服務器，系統就建立和運行了。我們開發了郵件通知、對象和連接監視、及診斷日志等功能。在你需要多個冗余的OPC服務器組使用同一個OPC服務器供應商的情況下，我們增加了對OPC服務器的ProgID的異名功能。

*提示：別名要求監測的OPC客戶端修改

可靠性
有很多變量都會影響數據的質量和可靠性，甚至更多的方法使一個OPC系統與一個OPC服務器失去連接。最常見的如下：

運行OPC服務器的PC關機
用戶失誤導致OPC服務器退出
OPC服務器失去網絡連接或網絡連接不可靠
The Network setting is changed causing link failure
由于一些原因OPC服務器自己停止了，原因包括已知或者其它
安裝OPC服務器的PC機的登錄賬戶更改了

在以上的大多數情況，OPC DA服務器由于實際故障而停止提供數據。這些類型的故障就是我們所說的基于對象的故障。當OPC客戶端應用程序和目標OPC服務器的實際連接斷開時，基于對象的故障就發生了。一瞬間考慮到工業上的應用會丟失數據的ways，我們必須記住一些因素。在先前的例子中，軟件是起因。但是，在應用程序中物理硬件的崩潰也能極度地影響可靠性。其中一些物理因素如下：

物理連接的失敗（電纜被拖拉）
硬件故障（路由器故障）
電氣接口（高電流放電）
由于信號傳送的延遲（無線線路）
環境因素（閃電）
隨機事故

在這些情況下，OPC服務器和客戶端的實際連接是完美無缺的，但是對于底層設備或系統物理連接是損壞的。這些類型的故障就是我們所說的基于連接的故障。當目標設備或系統的連接丟失時，基于連接的故障就發生了。在多數情況下，OPC服務器仍然在完全的運行中，但是僅僅不能為剩下的系統提供數據。

單點故障
下圖展示的是一個典型的OPC系統怎樣配置以及怎樣對故障敏感的。能夠看到，OPC DA客戶端應用程序都能訪問一個單獨的OPC服務器。在這種情況下，對于基于對象的故障和基于連接的故障這種可能均存在。如果由于一些原因單獨的OPC服務器停止工作，我們就會遇到基于對象的故障。另外，由于這個單獨的PC機負責從底層設備那里收集數據，對于設備連接也存在單點故障。為了增強你的OPC系統的可靠性，你需要消除這些單點故障。

消除單點故障，可以通過天衣無縫地增加RedundancyMaster，重新設計你的OPC系統來使用不止一個OPC服務器。

Single Point of Failure

RedundancyMaster用于兩個OPC服務器組
在下圖中可以看到，原始的OPC系統被重新設計，使用了兩個OPC服務器而不再是一個單獨的OPC服務器。為了使OPC服務器的冗余操作更簡單，每個OPC客戶端都成對地有一個RedundancyMaster。

使用RedundancyMaster中可配置的選項，主或輔OPC服務器的使用都能直接地控制。基于選擇的模式，RedundancyMaster將使兩個服務器都起作用或如果配置成這樣，那么僅當主服務器停止時啟動輔服務器。

至于基于對象的故障或基于連接的故障，RedundancyMaster可以配置為監測這些情況并阻止系統不必要的故障時間從而為你省時又省錢!

Two OPC Servers Paired with RedundancyMaster

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一次底層服務器以確定是否有數據丟失。通過快速的查詢，由于故障檢測更頻繁，可以最大限度地減少故障切換時間。

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

診斷設置:
在關機時保存時間到磁盤：當應用程序關閉時將事件保存到磁盤。下次啟動應用程序時，事件將顯示，任何新的事件也將在日志的最下方顯示。

M捕捉事件的的最大數：由于診斷要利用內存和存儲資源，你可能會想限制在任意給定時間內保存的診斷數量。一旦事件數量達到最大了，最久的事件將被必要地丟棄。

通知設置:
此功能允許你配置一個或多個收信人來接收針對一個或多個診斷事件的郵件通知。可發送郵件通知的事件是能夠在本地診斷設置查看中可見的事件。

Redundac．ｍａｓｔｅｒDiagrams:

廣播專有的以太網IP數據：
上圖展示了KEPServerEX的插件設備驅動如何控制專有的以太網IP數據變為OPC數據，然后這些數據會被分發給一個基本冗余系統中的OPC客戶端。

本地機器冗余：
這種情況有OPC客戶端，RedundancyMaster，及位于本地機器上的輔助OPC服務器和在遠程機器上的主OPC服務器。這種情況確保最可靠的服務器是你的輔助服務器。這種情況也減少了在另一臺機器上運行輔助OPC服務器的需要。

單個OPC服務器組冗余：
這是一個標準使用圖，針對一個服務器組，在此組中，RedundancyMaster作為OPC客戶端位于同一臺機器上，兩個OPC服務器在遠程機器上。

多個OPC服務器組冗余：
RedundancyMaster可以配置成有多個OPC服務器組。在此圖中，有兩組分別從兩個獨立的設備網絡中收集數據的OPC服務器。如果這多個OPC服務器組都是相同的ProgID （ KEPware.KEPServerEX.V4 ），那么你將需要使用別名功能，如果這兩組有不同的ProgIDs的OPC服務器，那么你將不需要別名功能。

RedundancyMaster客戶端接口
應用程序連接接口：
OPC數據訪問：1.0a、2.0、2.05a