¼¼»óÀÇ ¸ðµç OPC Server°¡ ´Ù ÀÖ½À´Ï´Ù !!

OPC ±³À° ÇÁ·Î±×·¥ ½Ç½Ã !!  To Download Agenda, click here

OPC Solutions

LinkMaster (OPC Bridging)

RedundancyMaster (OPC Redundancy)

OPC DataLogger (to RDB)

OPC Gateway (DA <--> UA)

OPC Protocol Converter

OPC Tunneller

OPC UA (Unified Architecture)

OPC UA Tunnelling

OPC HDA (Historical DA) Server

OPC A&E (Alarms & Events) Server

OPC A&E Historian

Industrial Big Data (IDF for Splunk)

IoT Gateway (MQTT, REST, ThingWorx)

Cogent DataHub

TOP Server (Software Toolbox)

Downloads

Kepware Redundancy Master

 

Kepware RedundancyMaster

an OPC Redundancy Solution

µ¿ÀÏÇÑ OPC Server 2°³¸¦ Primary(Active) ¿Í Secondary(Standby)·Î ±¸¼ºÇÏ°í, OPC Client¿¡¼­ Primary OPC Server¿Í Åë½ÅÁß ¹®Á¦°¡ »ý±â¸é ÀÚµ¿À¸·Î Secondary OPC Server¿¡ ¿¬°áÇÏ¿© µ¥ÀÌÅÍ ¼Õ½Ç¾øÀÌ Åë½ÅÇÏ°íÀÚ ÇÒ ¶§, OPC Client´Â ´ÙÀ½ÀÇ 3°¡Áö¸¦ ÀÌ¿ëÇÏ¿© OPC Server¿¡ ¿¬°áÇÑ´Ù. 

  • OPC Server's PC Name or IP Address
  • OPC Server Name (ProgID)
  • OPC Item(Tag) Name

OPC Server Name°ú Item NameÀº µ¿ÀÏÇÏÁö¸¸, 2´ëÀÇ PC´Â °¢±â ´Ù¸¥ À̸§À» »ç¿ëÇØ¾ß ÇϹǷΠOPC Client Application¿¡¼­ 2´ëÀÇ PC°£À» ÀÚµ¿À¸·Î Àýü(Fail-over)ÇÏ´Â ±â´ÉÀ» Á¦°øÇÏ¸é µÇÁö¸¸, ´ë°³ÀÇ OPC Client´Â ÀÌ·± ±â´ÉÀ» Áö¿øÇÏÁö ¾Ê´Â´Ù.  

Kepware RedundancyMaster´Â OPC Client PC¿¡ ¼³Ä¡µÇ¾î¾ß Çϸç, Primary OPC Server¿ÍÀÇ Åë½ÅÀÌ µÎÀýµÇ¸é ÀÚµ¿À¸·Î Secondary OPC Server¿¡ ¿¬°áÇÏ¿© High Availability¸¦ ±¸ÇöÇØ ÁÖ´Â ¼Ö·ç¼ÇÀÔ´Ï´Ù.
 

Easy Configuration
¾Æ·¡¿Í °°ÀÌ Primary/Secondary PC Name ¶Ç´Â IP Address¸¦ ÁöÁ¤ÇÏ¸é µË´Ï´Ù.

 

 

Secondary·ÎÀÇ Àýü´Â ¾Æ·¡ÀÇ °æ¿ì¿¡ ÀϾ´Ï´Ù.

  • Physical Connection Failure (the cable is pulled)
  • Hardware Failure (router failure)
  • Electrical Interference (high current discharge)
  • Delays due to signal propagation (radio links)
  • Environmental factors (lightning)
  • Random accidents

Connection Mode

  • Cold (Active machine only):
    In this mode, the application will only connect to one underlying server at a time. On startup, a connection to the primary server will be made and all client related requests will be forwarded onto the primary. In the event that the connection to the primary fails, or communications to the primary is lost, a connection to the secondary will be made. If the redundancy application is unable to obtain a connection to the secondary, it will continue to ping-pong between the two servers until it makes a successful connection.
  • Warm (Both machines, subscribe to items on active machine):
    In this mode, the application will attempt to maintain a connection to both the primary and secondary servers at all times. Only items in the primary server will be active and polled. In the event that the connection to the primary fails, or communications to the primary is lost, the identical items in the primary server will be set to active in secondary server. Periodically, both servers will be pinged to determine if the connection is still valid.
  • Hot (Both machines, subscribe to items on both machines):
    In this mode, the application will attempt to maintain a connection to both the primary and secondary servers at all times. On startup, the application will initialize data callbacks for both primary and secondary servers so that both servers will send data change notifications. The data received from the primary server will be forwarded onto the client. In the event that the connection to the primary fails, or communications to the primary is lost, data received for the secondary will immediately be forwarded onto the client.

OPC Server Aliasing:
This feature will allow you to configure multiple pairs of OPC Servers with the same ProgID (KEPware.KEPServerEX.V5). This feature permits you to use one OPC Server vendor if you have multiple OPC Server nodes on your network. This will allow OPC clients to connect to a specific redundant pair by referring to the aliased ProgID of that redundant pair.

Always connect to primary machine upon availability
This setting enables RedundancyMaster to automatically promote communications back to the primary machine when the OPC server becomes available.

Query Server Status Interval
This interval (specified in milliseconds) determines how often RedundancyMaster will ping the underlying servers to determine if there has been a loss of communications. By querying at a faster rate, you can minimize fail-over time since failure detection occurs more frequently.

Query Server Status Timeout
This interval (specified in milliseconds) determines how long the redundancy application will wait for a ping response from the underlying servers before considering there to be a loss of communications.

Monitoring Settings: This feature allows you to configure certain conditions which will initiate a fail-over to the inactive server. These conditions allow you to monitor server items for specific states to determine the health of the underlying servers/devices, above and beyond the automatic fail-over that will occur due to the loss of communications.

Multiple OPC Server Pair Redundancy RedundancyMaster can be configured to have multiple OPC Server Pairs. In this diagram there are two pairs of OPC Servers which are gathering data from two separate device networks. If the multiple OPC Server Pairs are all of the same ProgID (KEPware.KEPServerEX.V4), then you will need to use the Aliasing feature; if the two pairs have different OPC Servers with different ProgIDs then you will not need the Aliasing feature.

RedundancyMaster Client Interfaces
Application Connectivity Support:
OPC Data Access: 1.0, 2.05a, and 3.0

 

       BridgeWare

°æ±âµµ ¾È¾ç½Ã µ¿¾È±¸ ¹ú¸»·Î 66, A-F1106È£ (ÆòÃÌÇÏÀÌÇʵå)
Phone  031-346-1981(¿µ¾÷) 1982 (Áö¿ø)    Fax  0505-303-1964