• RedundancyMaster

    將多個 OPC Servers 設定為 Redundant Pairs
    概觀

    藉由允許將多個OPC Servers設定為redundant pairs, 來提高可靠性以及OPC資料的可用度。每一組redundant pair看起來就像是一組單一的OPC Server端對上任何OPC Client端之應用程式般的自然。
    RedundancyMaster可以加入現有的server/client應用程式中,且無需重新設定應用程式。保持您的流程順暢,不需要任何的停機時間。

    OPC Data Access( OPC DA) 技術已被證實,其技術在幾乎每一個可能的情況下要求將consistent data傳送至裝置以及系統上是可靠的。即使如此,還是有些因素會危害系統的完整性,像是軟體因素,硬體因素,甚至是人為的因素。透過OPC redundancy技術,您可以讓這些系統更加的可靠以及有效率。
    如果因為任何原因使得單一OPC server無法操作,那麼我們將會有基於物件的失敗。此外,因為這個單一PC負責底層裝置的資料收集,同樣地單點故障也存在於裝置的連接中。為了提高您的OPC系統的可靠性,您必須排除這些單點故障。要消除這些單點故障您可以增加RedundancyMaster來重新設計您的OPC系統,使其不只使用一個OPC server。
    RedundancyMaster駐在您的OPC Client端機器上,藉由”hooking”的方式在OPC Client端以及Server端之間呼叫,以方便連結系統網絡上的主要及次要的OPC Server。如果OPC Client端失去了與主要的OPC Server端之間的連結,或是目前情況觸發了使用者所設定的條件
    例如:一個物件(item)沒有接收到更新的資訊,達到了另一個指定的物件(item)所設的數值,或是該物件的通訊品質被設為bad時,RedundancyMaster會中斷與主要的OPC server的連接,並晉升次要的OPC server ─ 以減少系統停機時間和節省您的成本。
    RedundancyMaster可說是個開放性的應用程式,不需要對您的OPC client或server應用程式做任何的修改。其設定只需要幾分鐘,讓您在使用Redundant OPC系統上沒有煩惱。只需簡單的瀏覽並選擇您的主要及次要OPC Server,就能啟動系統並開始運作。我們的特點有:

    • E-mail通知
    • 物件及連結的監控
    • 診斷日誌(Logging)


    您可能會有想要使用相同的OPC Server Vendor,而需要數個Redundant OPC Server pairs的情況,為此,我們在OPC Server上的alias* the ProgID (Program ID))新增了這個能力。 *註: Aliasing也許會要求OPC Client做少許的修改。
    兩個OPC Servers Paired搭配RedundancyMaster

    如圖所示,原來的OPC 系統已經被重新設計,改成由兩個OPC Servers取代單一OPC Server的模式。為了使OPC servers的redundant操作便利,每個OPC client都和RedundancyMaster配對。 利用RedundancyMaster內的設定選項,無論是使用主要還是次要的OPC server都可以直接被控制,根據選定的模式,RedundancyMaster會讓主要以及次要的OPC Server保持啟動,或者是當主要的OPC Server出現錯誤時,啟用次要的OPC server。
    關於基於物件的失敗或是基於連線的失敗,RedundancyMaster都可以被設定來監視這些情況並且避免您系統中不必要的停機時間以節省您的時間及成本!

    可靠性

    有很多變數可能會影響資料的質量和可靠性或造成OPC系統與OPC Server斷線。常見的情況有:

    • 執行OPC Server的PC停止運作。
    • 使用者錯誤導致OPC Server退出。
    • 網路失去與OPC Server的連接或是兩者之間連結不可靠。
    • 網路設定改變導致連接失敗。
    • OPC Server因為本身已知或是其他的因素故障
    • 執行OPC Server的PC的登錄帳戶改變。

    大多數的情況下,由於OPC Server或與該Server的連線發生實體故障,OPC DA Server將無法繼續傳輸資料。這些故障類型被定義為物件故障(object-based)。關閉OPC Client的應用程式以及目標OPC Server就會發生物件故障。在這些案例之中,其中也包含軟體操作不當引發的故障。然而,實體硬體發生故障將會嚴重影響資料的可靠性。其中包含以下這些物理因素:

    • 物理上的連接失敗(電纜被拔除))
    • 韌體故障(路由器故障)
    • 電子干擾(高電流放電)
    • 由於訊號的因素而造成傳遞延遲(無線電連接)
    • 環境因素(閃電)
    • 隨機的意外因素

    在這些情況下,OPC Server和客戶端之間的虛擬連線表面看似正常,但是底層設備或系統的物理連結有可能處於故障狀態。以上這些故障類型被定義為連結故障(Link-based)。與目標設備或系統斷線時,就會造成連結故障。在大多數的案例裡,即使發生連結故障(Link-Based)OPC Server仍然可以正常運作,但要注意的是沒辦法再傳輸資料至休眠系統。

    使用RedundancyMaster來監控例外情況,並且能夠有效防止非必要性的系統停機,以達到節省時間和成本的效用。

    RedundancyMaster功能 :

    探索RedundancyMaster的功能將會改變您對OPC redundancy的想法。RedundancyMaster的創新可以完美無暇地和您現有的OPC應用程式一起運作以給予您更多可靠的解決方案

    指定與OPC Server連結的主要機器,以及當無法與主要機器通訊連接時,與OPC Server連結的次要機器。每當新的Client端連接至底層Server時,會先嘗試連接在主要機器上運作的Server。 若是主要Server的連結失敗,或是與主要Server之間的連結中斷的話,會嘗試連接到次要的Server,如果可行的話,會建立一個新連線。 根據不同的連線模式,你可以利用應用程式來設定,當主要機器恢復時,自動地建立和主要機器之間的通訊。
    此功能允許您設定多組具有相同ProgID(KEPware.KEPServerEX.V5)的OPC Servers。如果在您的網路上有多個OPC Server的節點的話,這個功能容許你使用一組OPC Server vendor。這允許OPC Client藉由參考Redundant pair別名化後的ProgID,來和該Redundant pair建立連接。
    透過此設定,在OPC Server恢復時,RedundancyMaster會自動恢復與主要機器的連線。
    此時間間隔(Interval)(以milliseconds為單位)決定RedundancyMaster確認底層Server的連接是否有中斷的偵測頻率。透過更快的速度查詢,您可以因為連線失敗的偵測更為頻繁,而大幅地縮短故障轉移(fail over)的時間。
    此時間間隔(以milliseconds為單位)決定Redundancy應用程式在判定失去連接之前會花多久的時間等待底層Servers的偵測回應。
    此功能能壤您設定特定的條件,來對非運作中的Server觸發故障轉移(fail over)機制。 這些條件允許您監視Server 物件(items)的特定情況,以確認底層Servers/裝置(Devices)的狀況, 一旦超出或低於條件時,通訊中斷的期間,將所自動觸發故障轉移(fail over)。
    關閉時,將事件(events)儲存在硬碟上:當應用程式關閉時,事件將會被保存在硬碟中。在下次重新啟動應用程式時,將會顯示該事件,且會將所有新的事件串聯在舊的事件之後。 捕捉事件(events)的最大數量:由於診斷是利用記憶體以及儲存資源,你也許想要在系統給予的時間內,限制診斷的次數。一旦達到事件的最大值,將刪除舊的事件。
    這個功能允許您能夠設定數個收件人,來接收數個診斷事件的Email通知。用於發送Email通知的事件,也可以在本機的診斷設定視窗中瀏覽。
    連接模式

    連接模式定義redundancy應用程式如何及何時去連接底層的主要及次要的Server。您操作的模式將會影響故障轉移(fail   over) - 從一個OPC server切換到另一個OPC serve所花費的大部分時間。有些模式允許當主要機器恢復時,自動幫您將通訊連接至主要機器上,以下是連接方式的總結:
    *其中冷模式只適用於運作中的機器,而溫模式、熱模式適用於機器,以及運作中的機器所認同的物件(items)。

    在這個模式之下,應用程式只會在一個時間點內,連接一個底層的Server。
    啟動時,會與主要server建立連結,並且將所有來自Client端的相關請求轉移至主要Server。若是主要Server的連結失敗,或是與主要Server之間的連結中斷的話,將會與次要的Server建立連結。 如果redundancy應用程式無法獲得與次要Server的連接時,會在兩個server之中產生乒乓效應(ping-pong effect)來回偵測,直到成功的連線。

    這種冷模式的連接方式大幅地減少已經被分配的系統資源的消耗量,因為在系統給予的時間內,只會有一個連結與一個Server連接。它也降低了網路流量,因為就像在其他的模式一樣,不需要在非運作中的機器和運作中的機器之間輪流連接。這個設定的缺點是故障轉移(fail over)到非運作中的機器所需花費的時間量。當運作中的Server察覺通訊連接中斷時,應用程式需要建立一個連接到非運作中server,取得代表所有物件(items)的Client端的同意,並啟用適當的回調(callback)機制。

    在這個模式之下,應用程式會試圖在任何時候保持主要及次要Server之間的連接。
    只有主要Server中的物件(items)會被啟用並且調查。若是主要Server的連結失敗,或是與主要Server之間的連結中斷的話,在次要Server中,與主要Server相同的物件(items)將會被啟動。 每隔一段時間會同時偵測兩個Server,以確定連接是否仍然有效。

    這種溫模式的連接方式增加了系統資源的分配,畢竟是由兩個Server的連接來代表Client端。 因為是每隔一段時間偵測兩個server,而不是一個server,所以也增加了少量的網路流量,就像冷模式的運作。這個模式的優點是故障轉移(failover)的時間,比起冷模式所需的時間要少很多,redundancy應用程式只需將資料初始化,然後呼叫非運作中的Server起來接收資料。 如果您需要減少應用程式的資料流失,同時想要減少網路流量,您應該要選用這個連接模式。

    在這個模式之下,應用程式會試圖在任何時候保持主要及次要Server之間的連接。
    啟動時,應用程式會為主要及次要Server將資料初始化並且回傳,以便讓這兩個Server發送資料更改的通知。從主要Server那接收的資料會被轉發到Client端。 若是主要Server的連結失敗,或是與主要Server之間的連結中斷的話,從次要Server那收到的資料會被立即轉發至Client端。無論如何,寫入的資料只會被轉發到運作中的Server。 每隔一段時間會同時偵測兩個Server,以確定連結是否仍然有效。如果redundancy應用程式與任一Server之間的連接中斷時,它會週期性地嘗試與連線中斷的Server重新連接。

    這種熱模式的連接方式增加增加了系統資源的分配,畢竟是由兩個Server的連接來代表Client端。因為除了接受蘭自兩個底層Server的資料改變通知之外,它也會週期性的同時偵測兩個server以確定連結是否仍然有效,所以造成網路流量的增加。 這個設定的好處是在當偵測到失去和運作中Server的連接後,它會立即啟動故障轉移(failover)機制。如果資料遺失是您應用程式中非常關鍵的一點,您應該選擇這個連接模式。

    使用案例

    如果多個OPC DA Client應用程式同時存取單一OPC Server,就會有物件故障或連結故障的潛在風險存在。可能會因為某些原因而導致OPC server物件故障,造成無法正常運作。
    此外,因為單一PC是從底層設備抓取資料,因此在連接設備時也存在著單點故障的風險。

    為了提高OPC系統的可靠性,必須使用多個OPC Server來重新設定OPC系統來排除單點故障。為了方便操作OPC Servers的Redundant,每個OPC客戶端都需配置RedundancyMaster。 使用RedundancyMaster的設定選項,能夠直接控制OPC Server的主要伺服器和次要伺服器。

    根據所選擇的模式,RedundancyMaster將會維持雙方Server的運作或當主要伺服器發生故障時,啟動次要伺服器(如果RedundancyMaster有設定此項功能)。

    這個方案包含了OPC Client、RedundancyMaster,次要OPC Server駐留(reside)在本機中,以及主要OPC Server駐留在遠端機器。在這個方案中,一定會讓您的次要OPC Server成為最可靠的Server 。
    而這個方案也減少了由其他機器來營運次要OPC Server的需求。

    RedundancyMaster可以被設定為擁有多個OPC Server Pair,在這個圖表中,有兩組OPC Server從兩個不同的裝置網路來收集資料,如果多個OPC Server Pair都是相同的ProgID(KEPware.KEPServerEX.V4),那麼您就需要使用 別名化(Aliasing)的功能。
    如果兩個pair之間有不同的ProgID的不同OPC Servers,那麼您就不需要使用 別名化(Aliasing)的功能。

    資源

    應用程式支援
    • OPC Data Access (OPC DA) Versions 1.0 and 2.05a
    作業系統
    • Windows 8
    • Windows 7 Professional/Enterprise/Ultimate
    • Windows Server 2012
    • Windows Server 2008 and 2008 R2
    • Windows Vista Business/Enterprise/Ultimate
    • Windows Server 2003 SP2
    • Windows XP Professional SP3 or higher
    系統需求
    • 2.0 GHz Processor
    • 1 GB installed RAM
    • 180 MB available disk space
    • Ethernet Card
    • Super VGA (800x600) or Higher Resolution Video

    相關問題諮詢

    若有任何問題,歡迎與我們聯繫!


Please publish modules in offcanvas position.