Optimizing OPC Communications with OPC Middleware Products

OPC middleware products are designed to enhance any OPC-based application. An intelligent set of OPC products simplifies the commissioning and operation of OPC clients and servers, significantly improves the data throughput of your OPC interfaces, and ensures reliable OPC communication links.

Originally, OPC was defined as a standardized solution for the recurring task of connecting PC-based applications (for example HMI or SCADA systems) with automation and process control devices. Today, the OPC standard has evolved into a robust data carrier able to transport entire enterprise resource planning documents and even video signals.

However, this great success story of OPC is accompanied by some caveats. For example, standard OPC DA (Data Access) is based on Microsoft’s COM and DCOM technology and is consequently restricted to the Windows operating system. In addition, DCOM communication is easily blocked by firewalls that prevent OPC clients from accessing data over a wide-area network and the World Wide Web.

There are a growing number of applications that need to go beyond the standard OPC DA architecture. For example, some applications would greatly benefit from OPC client-to-client and/or OPC Server-to-Server communication relationships that are not foreseen by the current OPC DA specification.

Other unforeseen scenarios include

  • OPC communications between different operating systems or through firewalls
  • OPC applications that consist of a large number of Clients communicating with a single OPC Server and thereby pushing most Servers to its limits with the sheer amount of requests
  • OPC applications that have a single OPC Client that communicates with a large number of OPC Servers. The OPC specification does not include hard rules for naming OPC items. Therefore, OPC namespaces of OPC Servers from different vendors are probably very dissimilar making it very cumbersome for control engineers to configure/maintain large systems
  • OPC applications that require data encryption while communicating with remote hosts.

    The remainder of this document will discuss techniques to effectively complement the OPC standard with OPC middleware products that help to alleviate most problems a user might face. At the same time, these middleware products will significantly improve the data throughput between OPC entities, ensuring reliable OPC communication links.

    OPC communications without DCOM
    The Component Object Model (COM) is a binary interface standard for software components introduced by Microsoft in 1993. It is used to enable inter-process communication and dynamic object creation in a large range of programming languages. The term COM is often used in the software development industry as an umbrella term that encompasses the OLE, OLE Automation, ActiveX, COM+, and DCOM technologies.

    The Distributed Component Object Model (DCOM) is also a proprietary Microsoft technology for communication among software components distributed across networked computers. DCOM, which originally was called "Network OLE", extends Microsoft's COM, providing the communication substrate under Microsoft's COM+ application server infrastructure.

    The idea behind DCOM is simply that it “can make distributed applications secure without any security-specific coding or design in either the client or the component .” Sounds good, but the reality is a little bit different. The security demands on Windows has increased and changed with every new version or service release for the operating system. This constant “patching of security holes” has made it extremely tricky to correctly configure DCOM within a set of computers running different versions of the Microsoft OS.

    Have you ever had the pleasure of configuring the security settings for DCOM to make your OPC application run in a network? It is not easy to say the least. A seemingly easy task of setting up a link between two OPC components can quickly turn into a nerve-wracking struggle with the security settings of the underlying DCOM system. Here is the good news: There are alternatives to using DCOM for OPC applications that are worthy of consideration when setting up OPC connections between computers.

    One common approach is to tunnel OPC communications over TCP/IP to a remote computer. The use of such an OPC Tunnel product (e.g. Softing’s OPC Tunnel; part of Softing’s OPC Easy Connect Suite) is an effective solution that bypasses DCOM completely. The OPC Tunnel enables high-performance and robust communications between OPC components on networked computers. OPC Tunnel components are installed on both the OPC client computer and the OPC server computer. Communications between the client-side and server-side OPC Tunnel components is realized over a TCP/IP connection (encrypted, if desired). The data between client and server applications is thus tunneled via TCP/IP, bypassing DCOM completely and eliminating time-consuming DCOM setup work.

    As an additional benefit, a few advanced OPC Tunnel products augment the current OPC standard by offering optional security features such as user authentication by remote OPC Clients to prevent unauthorized remote access.

    OPC Client to Client and OPC Server to Server
    Other OPC middleware products are complementing the OPC standard by enabling OPC Client to Client and OPC Server to Server communication relationships that are not specified in the OPC standard.

    An OPC Client to Client link can be used to synchronize PC-based control applications with visualization packages without burdening the underlying OPC Server(s) with additional data requests.

    OPC Server to Server communications can be used to elegantly merge heterogeneous automation systems. For example, an OPC Server supporting Ethernet/IP can access Rockwell Automation devices while Softing’s S7 OPC Server can access Siemens-based automation equipment. Linking these two OPC Servers effectively bridges between automation systems predominantly used in the US and automation systems predominantly used in Europe.

    The key in supporting these classes of non-standard OPC communication relationships is to use an OPC-Gateway. The OPC-Gateway represents a man-in-the-middle architecture translating between two (or more) Clients or Servers. In case of a Client to Client architecture the OPC-Gateway acts as an OPC Server that serves both Clients. The main task of the OPC-Gateway is to cross-map the data that flows between the OPC Clients. In case of a Server to Server relationship the OPC-Gateway takes on the role of an OPC Client. The OPC-Gateway simply cross-maps input data from the one Server to the output data of the other Server and vice versa.

    All for One and One for All
    OPC applications that involve a large number of OPC Clients that access a single OPC Server often overwhelm the capability of the server. A common problem is that some servers only support a limited amount of OPC groups . Another is that poorly implemented OPC servers simply cannot keep-up with all OPC requests and start to slow down the overall system performance while at the same time consuming the limited computer resources of the host processor.

    What is needed is some kind of OPC Optimizer that is specifically designed to step between OPC Clients and an OPC Server under pressure. For example, Softing’s OPC Optimizer is based on Softing’s exceptional OPC Development Kit and employs a unique and proprietary algorithm to optimize the data throughput between the OPC Server and the connected OPC Clients by automatically re-combining and optimizing OPC Read and Write Requests. Combined with an exceptionally efficient OPC implementation, the OPC Optimizer not only removes the pressure on any OPC Server but at the same time provides the required data throughput demanded by large scale industrial systems.

    Interestingly, the reverse system architecture of having one OPC Client communicating with multiple OPC Servers does produce a very different set of problems. True, some OPC Clients do work better when communicating to only one OPC Server but this is not the big issue on hand. It’s the OPC namespace that can become very cumbersome to manage. Imagine if all OPC Servers in a system are from different vendors and each vendor has a different idea on how to “name” the OPC Items. This has the potential to quickly turn into a nightmare for control engineers in charge of configuring and maintaining a large OPC application.

    One solution to this problem is to consolidate or concentrate all namespaces into one with an OPC Concentrator, yet another middleware product. The OPC Concentrator combines (concentrates) multiple OPC Servers into a single OPC Server by consolidating
  • all OPC namespaces into a single namespace
  • the data of multiple OPC Servers into a single OPC Server.

    This data concentration combined with the standardized access to third-party servers by methodically encapsulating multiple namespaces significantly simplifies the commissioning and maintenance of HMI or control system applications. This positive impact becomes very apparent when dealing with large projects.

    But wait, there is more…
    So far this document has only discussed the OPC DA architecture that depends on the Windows operating system. There are, however, two additional OPC specifications that go beyond the original OPC DA standard.
    1. OPC XML-DA – This OPC standard does not rely on DCOM and is freely portable to non-Windows operating systems. The disadvantage of XML-DA is its somewhat lower performance.
    2. OPC UA (Unified Architecture) – This is the latest OPC standard that will free OPC completely from any dependence on Windows or any other operating system. In addition, the emerging OPC UA technology does not compromise high-performance and reliability requirements making it a supreme candidate for embedding OPC technology directly into end-devices.

    But how do you exchange data between the traditional OPC DA products and OPC XML-DA or OPC UA components?

    The helper application called upon to solve this compatibility gap is the OPC Bridge. The OPC Bridge is used to transparently translate XML-DA and OPC UA into the COM/DCOM world of traditional OPC products (and vice versa) thereby enabling the seamless integration of OPC products that are based on different revisions of the ever-evolving OPC standard.

    There are several other middleware products that help streamline OPC projects. One application scenario that has become more prevalent in recent years is to directly store process data into a database. There are quite a few off-the-shelf solutions available that support this requirement. The majority of them are implementing two helper applications:
  • OPC Collector
    An OPC Collector is an independent Data Access and/or XML DA client used to capture OPC data from any DA or XML DA server. Typically, the OPC Collector integrates with other OPC middleware products that take the captured OPC data and process it, save it, analyze it, or transfer it to OPCtoDataBase or OPCtoFile.
  • OPCtoDatabase
    OPCtoDataBase stores OPC data from any Data Access or XML DA server in standard databases including Microsoft SQL Server, Oracle, MySQL, IBM DB2, and other ODBC-compliant databases. Typically, the collected data is archived in databases using simple SQL statements.
  • OPCtoFile
    OPCToFile streams OPC data directly into standard text files (e.g. *.txt, *.html, *.xml). The support of configurable TEXT statements transform this helper application into a powerful extension to the current OPC standard.

    In summary, an intelligent set of high-performing OPC middleware products, similar to Softing’s Easy Connect Suite, can help to
  • considerably simplify the commissioning and operation of OPC clients and servers,
  • significantly improve the data throughput of OPC interfaces, and
  • ensure reliable OPC communication links.

    Softing, a member of the Technical Advisory Committee (TAC) of the OPC Foundation and author of the OPC Book, actively contributes to the success of OPC by providing high quality OPC products, enabling its customers to stay in the forefront of the industrial communications technologies they deploy.