KEPServerEX是工業界領先的通訊平台,它提供了單一來源的工業自動化資料給你所有的應用程式。此平台的設計,允許使用者經由直觀的使用者界面來連接、管理、監視和控制各種自動化裝置及應用軟體系統。
KEPServerEX利用OPC(操作互通性的自動化產業標準)和常用IT通訊協定(例如SNMP、ODBC,和web services)來提供單一來源的工業資料給使用者。此平台被開發和持續測試,以符合客戶在效能、可靠度和簡易使用上的各種需求。藉由增加REST和MQTT界面到OPC和OPC UA,讓它成爲物聯網必備之絕佳工具。
KEPServerEX提供有集中式的資料存取、彙整、最佳化、連接性、安全性,和診斷等等,各種嚴謹的技術特性。 獲獎無數的KEPServerEX擁有多達250種以上的通訊協定,可連接到各種系統、裝置和感測器,它也是市面上最通用的OPC server。
KEPServerEX提供最廣大範圍的驅動程式,支援橫跨各種產業所使用的自動化裝置。絕大多數的驅動程式扮演主動方(master)的角色,向裝置發出資料讀或寫請求。其中有許多驅動程式也可以在控制器爲主動的情形下,模擬成裝置來運作。
KEPServerEX的驅動程式也支援多樣的有線或無線網路媒體,包含Ethernet、序列,和各種專屬網路。雖然絕大多數的驅動程式是直接連接到硬體裝置,有些是被設計成連接其它應用軟體系統,例如資料庫、客製化軟體程式,或是其它的OPC server。
KEPServerEX製作有存取到業界領導品牌的自動化軟體系統,包含GE Intelligent Platforms (NIO)的iFIX,和Wonderware (SuiteLink/FastDDE)的InTouch。它也提供存取到ThingWorx® IoT平台,以快速開發和部署物聯網所需的智慧連接方案。
OPC是工業自動化連接的領先標準。KEPServerEX支援OPC Unified Architecture (OPC UA)規範和OPC傳統規範,包含OPC Data Access (OPC DA)、OPC Alarms & Events (OPC AE),和Historical Data Access (OPC HDA)。
有了IoT Gateway,KEPServerEX可以無縫串流即時的工業控制資料直接到巨量資料和分析軟體,給商業智慧系統和營運優化系統。它的可客製化資料格式支援大多數的MQTT和REST應用程式,讓使用者得以爲他們的系統選擇正確的供應商和通訊方式。
IoT Gateway也提供了ThingWorx Agent,使用安全的ThingWorx AlwaysOn™通訊協定,來高吞吐量地移動工業資料到ThingWorx物聯網平台。
KEPServerEX是一個支援同時連接到數千個資料來源,並提供資訊給數千個應用程式的通訊平台。此平台設計,藉由提供單一進入點來取得所有資訊,簡化了應用程式在連接上的規劃。
KEPServerEX也可啓用除錯和問題診斷機制,依據使用者的角色來控制存取,並提供限制通訊頻率機制給頻寬受限的使用環境。
若有任何問題,歡迎與我們聯繫!
LinkMaster 提供在OPC Servers之間連結資料的方式, 因此扮演猶如OPC Systems的萬用橋樑。此外, LinkMaster 是一個 OPC 與 DDE server ,允許它扮演成舊版DDE
systems 以及新的 OPC 程式之間的一個橋樑。
可以倚賴 LinkMaster 的產業,包含:航空業、 製程自動化、建築自動化、材料處理、醫藥 、 發電、 金屬製造、 紙漿和造紙業、 石化與煉油業、 林木業、 公用事業等。
LinkMaster 是一個快速且穩健的Windows應用程式,不需要程式設計的知識,只要以簡單的 拖拉即可建立你的links。內建數值調整scaling功能、使用者存取的管理、錯誤追蹤以及寫入最佳化的功能,提供你的資料流通以及應用程式存取之完整控制。
Link Groups 是用來集合以一個指定的速度在OPC servers間移動的OPC items資料。使用多個 Link Groups,LinkMaster 允許你控制從一個OPC server轉送資料到另一個OPC server的速度。 藉由使用 Link Groups ,你可以以不同的更新速度來控制你的資料轉送來配合應用程式的需求。當一個 item 可能需要以高速傳送,其他在應用程式裡的 items 可能需要較低的更新速度,在LinkMaster中都可以得到控制。 它的好處是可以減少網路的流量且增加可靠度。
對linkMaster來說最普遍的方案是在兩個(或是更多)OPC Servers之間來連接資料,一個可能的例子是一個客戶使用 RSLinx 來連接到 Allen Bradley PLCs, 以及 Kepware的 U-CON Protocol Server來連接到一個磅秤測量儀。在這個範例裡,客戶可以簡單的發送秤重資料到PLC。
另一個LinkMaster有趣的應用方式是以服務從多個OPC servers來的資料之單一OPC server的方式來運作。 此方式展示了LinkMaster可以同時扮演client與server的能力。這樣的例子是,當有一個客戶只能從一個OPC client應用程式連接到單一OPC server,但有需要從多個OPC servers取得資料時。
在一個客戶想要在連接到同一個server的兩個PLCs之間轉送資料時,通常會使用到這個方式。 使用 LinkMaster 來定義 tag data routing 比在你的PLCs裡建立一個新的ladder logic還要簡單(尤其對舊版的系統來說)。 一個可能的例子是一個客戶使用 KEPServerEX 來連接一個 Allen Bradley ControlLogix PLC 和一個 Yokogawa DX Data Recorder。
若有任何問題,歡迎與我們聯繫!
藉由允許將多個OPC Servers設定為redundant pairs, 來提高可靠性以及OPC資料的可用度。每一組redundant pair看起來就像是一組單一的OPC Server端對上任何OPC Client端之應用程式般的自然。
RedundancyMaster可以加入現有的server/client應用程式中,且無需重新設定應用程式。保持您的流程順暢,不需要任何的停機時間。
如圖所示,原來的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或與該Server的連線發生實體故障,OPC DA Server將無法繼續傳輸資料。這些故障類型被定義為物件故障(object-based)。關閉OPC Client的應用程式以及目標OPC Server就會發生物件故障。在這些案例之中,其中也包含軟體操作不當引發的故障。然而,實體硬體發生故障將會嚴重影響資料的可靠性。其中包含以下這些物理因素:
在這些情況下,OPC Server和客戶端之間的虛擬連線表面看似正常,但是底層設備或系統的物理連結有可能處於故障狀態。以上這些故障類型被定義為連結故障(Link-based)。與目標設備或系統斷線時,就會造成連結故障。在大多數的案例裡,即使發生連結故障(Link-Based)OPC Server仍然可以正常運作,但要注意的是沒辦法再傳輸資料至休眠系統。
使用RedundancyMaster來監控例外情況,並且能夠有效防止非必要性的系統停機,以達到節省時間和成本的效用。
探索RedundancyMaster的功能將會改變您對OPC redundancy的想法。RedundancyMaster的創新可以完美無暇地和您現有的OPC應用程式一起運作以給予您更多可靠的解決方案
連接模式定義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)的功能。
若有任何問題,歡迎與我們聯繫!