SplitOPC – OPC DA 2.0 Server / Tunneler

SplitOPC is an advanced OPC DA server and tunneler for local and distributed applications. It allows you to build hierarchical data acquisition from numerous sources and control systems while ensuring complete transmission of data and telecontrol signals in OPC format.

One of the main features of the SplitOPC is its capability to operate on low-quality communication channels, allowing you to use it in remote locations having only limited communication capabilities.

The server creates a network of routes by organizing communication channels among the OPC applications in complex distributed networks.

SplitOPC is fully compliant with OPC DA ver. 2.0.


The SplitOPC server / advanced tunneler combines data from the field equipment and distributed controllers into a single virtual data system. All the process data is collected from the heterogeneous OPC servers that operate on the geographically remote computers. Tag names are consistent throughout the system and follow internal company standards. All the computer names are also unified. The end-user can access any enterprise data as if it was located on one computer only. On top of this, the operator’s visible area can be limited only to one segment of the system.

SplitOPC acts as:
– OPC server. For the user’s OPC clients to have access to the process data of the company.
– OPC client. To collect process data from OPC servers from the same computer.

Unlike conventional OPC tunnelers, SplitOPC does more than just overcoming the disadvantages of using DCOM protocol but also becomes a constructor of the hierarchical data system.


It often happens that communication lines have low bandwidth to the most distant nodes of the system. When using a conventional OPC tunneller, when several users need data from the remote node, they will use several separate tunnel connections. The load on the communication channel will increase in proportion to the number of users. In the case of a system built with SplitOPC, only one connection is established to each remote node from the tree’s upstream node. This approach leads to a significant gain in the speed and availability of the data.

Calculated tags

SplitOPC allows you to aggregate data via calculations on the received data. For example, one of the nodes in the system has several flow meters, and users at the central nodes don’t need separate data for each of the meters but instead an aggregate gas consumption for the node. In this case, SplitOPC calculates the summarized tag according to the formulas set by the user and transmits its data to the upstream nodes. On top of this, data from each of the flow meters can also be received from different OPC servers. This leads to the optimization of the communication volume to the central nodes. And the use of the calculated tags allows unifying the units of measurement. For example, pressure can be transmitted only in megapascals.

Renaming (aliasing)

Companies often use a wide range of equipment, and access to the data from one or the other technological processes is carried out via heterogenous OPC servers. Each of these OPC servers has its system of naming for the parameters (tags). It increases complexity and creates confusion in use while making the creation of one consistent data system more difficult. SplitOPC allows renaming of the tags from the local OPC servers or tags received from other nodes. It significantly improves the ease of building a consistent approach across the system.

Limitation of the scope for nodes

Despite the ability to receive any data from anywhere in the system based on SplitOPC, sometimes it is required to limit the scope for certain nodes. SplitOPC allows you to restrict access to data for particular nodes.

Operation as a service

SplitOPC can be used in both user interface mode and service mode. It is convenient to make all the settings, visually make sure that the system is working correctly in the user mode interface, and then switch the SplitOPC operation to service mode. Nevertheless, even in service mode
it remains possible to configure the program and restart the application using service tags.

  • “End-to-end” data transmission, regardless of the location of nodes in different segments of the local / global network while taking into account the installed firewall.
  • Automatic search and creation of optimal routes between OPC destinations (dynamic rerouting). If the existing route fails, the best alternative route is found automatically.
  • Hot standby of the primary server with automatic “takeover” of the role by the redundant server.
  • Support for global OPC tag alias tables. The creation of aliases for signal names allows you to build an ordered structure of names in the system, as well as provides wide opportunities for scalability and integration of various existing I&C systems into a single system.
  • The system of naming signals with unique names for each signal, similar to the domain name structure (DNS), allows you to accurately determine which level the data belongs to. For example, an operator in Kassel, Germany by the name of the tag IT.VEN.MSTR.CMP.Pout, accesses the signal value with the name 142_Pout, generated by the controller in Mestre, Italy.
  • Performing logical and arithmetic operations allows you to process data by creating new tags based on user-specified conditions.
  • The presence of a software gateway, implemented as a separate dynamic library, makes it possible to receive data from real-time systems (QNX, RT-Linux, RTKernel, etc.) in OPC format.
  • Assignment of access rights to certain groups of signals prevents the possibility of unauthorized issuing of a command or changing values.
  • High speed of transmission of a large number of tags (about 200,000) in real time, the use of unique compression algorithms that allow you to transfer the required amounts of data over low-speed communication channels.