This article mainly introduces OPC and Plug and Play technology, focusing on the development, technology, characteristics, applicable scope, and interface applications of OPC in practical applications. Background of OPC Development: Automation engineers have a beautiful dream: to achieve universal connectivity between automation control software and hardware, eliminating the need for drivers and interface issues—a very simple Plug & Play. Using OPC (OLE for Process Control) can help realize this dream. Users are naturally very interested, and it has won the support of automation software manufacturers—the first OPC products were launched on the market ahead of the date set by the standardization committee. In the past, few communication technology specifications in the automation field have caused such a stir as the new technology standard OPC. OPC is an abbreviation for OLE for Process Control, and today it has naturally been developed into a de facto new technology standard by automation component manufacturers. OLE (Object linking and embedding) means object linking and embedding for process control. Today, the importance of software in the field of automation is increasing daily. Regardless of whether a project involves operation, visualization, data archiving, or control, the trend towards purely PC-based software solutions is unstoppable. Time has proven that these software solutions are no longer developed as individual blocks, but rather as components composed of dedicated, single software parts. The ability to use reusable modules and leverage their flexibility to construct entire systems seems irreplaceable, with the sole exception of communication interface incompatibility. The time and money invested in adapting these communication interfaces are essential for integrating these software modules. This has led to the development of hundreds of communication interface software programs, such as those for process control or visualization systems to communicate with peripheral devices. However, this also significantly increases costs. OPC offers a remedy for this situation: OPC allows software components, such as software connectors, to communicate with each other without special adaptations. Therefore, plug-and-play becomes a reality in automation. This answers the question of why OPC is needed. The need for OPC can be explained from the following two points: First, for early computer systems, developing independent communication programs required significant time to achieve data exchange and communication between computers with different hardware and software. However, the existence of industry standards for data exchange and communication has made it possible to create a vast network like the Internet, connecting different computers. Therefore, when developing enterprise information systems, using industry-standard databases and client-server interfaces allows for more focused effort on developing the application's functionality. Second, industrial manufacturing systems face the same challenge: enabling interconnection between machines from different suppliers without requiring specialized software development. For example, in implementing a multi-layered production control information system like the one shown in Figure 1, establishing and popularizing an effective data exchange industry standard is crucial, from the field equipment layer processing equipment data to the process control system layer handling process data, and finally to the top-level production management layer. In this context, utilizing OLE/COM technology in Microsoft Windows to standardize data exchange in industrial manufacturing process control is precisely the purpose of OPC (OLE for Process Control). What is OPC? OPC defines an open interface on which PC-based software components can exchange data. It is based on Windows' OLE (Object Linking and Embedding), COM (Component Object Model), and DCOM (Distributed COM) technologies. Therefore, OPC provides an ideal method for connecting typical field devices in the automation layer to industrial applications and office programs. The introduction of standard interfaces for Windows programs reduces the number of interface programs hardware manufacturers need to develop for their components to one—only one interface program for the OPC server. Similarly, software manufacturers only need to develop a single communication interface program—the OPC client interface. This benefits not only manufacturers but also end customers. Therefore, a specific analysis of OPC based on COM technology is necessary. COM-based OPC: Microsoft developed the so-called Component Object Model (COM) technology to provide interoperability between commercial applications and purpose-built software packages. COM is an efficient method for exchanging data between software components. It is a binary and networking standard. It is also the core of DCOM, ActiveX (ActiveX is an update and upgrade of the widely used OLE control technology. It relies on COM technology and is a renaming and reconstruction of OLE control technology), and OLE technology. COM technology has the following advantages: * COM is not a computer language; it is independent of the machine running it, the machine's operating system (as long as it supports COM), and the software development language. It is a binary and network standard that allows any two software components to communicate with each other. * A COM server is an executable program that provides COM services according to the requirements of COM clients and can be distributed as an executable file on a Win32 server. * COM client programs and COM servers can be developed in completely different languages. This allows programs developed using different languages ​​such as C++, Visual Basic, and Visual Basic applications used as macros in Excel to interlink with each other. * COM components can be distributed to users in binary form. * Compared to the past difficulties in version management of DLLs (Dynamic Link Databases), COM technology can provide maximum compatibility between different versions of COM servers and COM client programs. * As an extension of COM technology, Distributed Component Object Model (DCOM) technology allows COM components to be distributed across different computers and interconnected via a network to exchange data. Therefore, for a COM client program, connecting to a COM server on a remote computer is similar to connecting to a COM server on a local computer. While the communication speed may differ, the key advantage is that it allows for the free construction of interconnected components on a network, as shown in Figure 2, using COM and DCOM (Distributed COM). The emergence of COM technology provided the technological foundation for easily implementing data exchange between control devices and control management systems. However, without an industry-standardized COM interface, interconnection between COM components developed by different control device manufacturers remains impossible. The provision of such an industry standard is the purpose of OPC. In short, OPC is a special COM interface defined as an industry standard. Comparison of OPC and DDE: Before the advent of OPC technology, DDE (Dynamic Data Exchange) technology made significant contributions to process control. However, DDE is a technology built on Windows message passing, so DDE technology has the following problems: * Slow data transmission speed * Lack of security management mechanism * Difficult development * Lack of functional flexibility * Unsatisfactory reliability. Therefore, it is natural that OPC technology, based on advanced COM technology, will gradually replace DDE, which is now widely used in process control. With the introduction of OPC technology, compared with the past DDE technology, it shows its superiority in the following aspects: * High-speed data transmission performance * Security management mechanism based on distributed COM * Reduced development cost * Realization of systems with highly flexible functions * Realization of systems with high reliability. Figure 3 shows an example of the experimental results of data transmission performance using OPC and DDE respectively. From this, we can also see the superiority of OPC technology in transmission speed. How users benefit from OPC In the past, usually only a limited number of interface programs were compatible with dedicated automation components. As we all know, it is impossible to develop interface programs for all dedicated interfaces. The obvious innovation today is that users can combine any visualization or control system with any hardware of choice (i.e., PC board) via OPC, as shown in Figure 4. As shown in Figure 4, the OPC standard software bus enables the integration of various fieldbus systems, such as PROFIBUS networks, CANopen (Open Controller Area Network), and DeviceNet. Figure 4 also vividly illustrates the relationship between OPC and fieldbus standardization: OPC provides important additional performance beyond fieldbus, and the main goal of fieldbus standardization is fast and reliable data transmission. OPC enables standard communication to such an extent that any OPC server and application software can network and operate without any problems. In Figure 4, PROFIBUS is an internationally recognized open fieldbus standard and a component of the international standard IEC 61158 Type III. Improvements in interface programs and OPC server quality further extend these advantages, allowing manufacturers to focus their efforts on developing a unique OPC server without dealing with numerous interface programs, enabling them to concentrate on adding additional functionality and improving operator friendliness. Furthermore, conformance testing implemented by the dedicated OPC Foundation promotes improved OPC product quality. In the past, the use of dedicated interface programs often limited to a single application. An application can now access an OPC server through an OPC interface with multiple clients. This allows for more flexible access to the OPC server's functionality and internal data. This multi-client capability not only benefits local PCs but also enables its use on distributed networks via DCOM (Distributed Component Object Model). For example, a visualization system running on an office computer can connect to an OPC server located in a factory without purchasing additional interface software. The flexibility and high level of mobility of OPC offer the following benefits to manufacturers and users: * Equipment developers: Enables the standardization of device driver development. * Application software developers: Utilize common development tools. Eliminates the need to develop specialized interfaces, simplifying device interface development. * Users: Offer access to a wide variety of commercial software packages, significantly reducing system configuration costs. It also facilitates the integration of industrial control systems using equipment from different vendors. With the promotion and widespread adoption of OPC-based control components, not only is the addition and replacement of control systems simplified, but access to process data also becomes easier. For example, process control programs can directly connect to data analysis software packages or spreadsheet applications, thereby achieving a high degree of informatization of the factory control system. Therefore, we can analyze in detail how OPC solves your problem. Before the advent of OPC, there was no unified standard for the interface between hardware drivers and the applications they connected to. For example, in the field of Factory Automation (FA), connecting control devices such as PLCs (Programmable Logic Controllers) and SCADA/HMI software requires different FA network systems. According to a survey, in the cost of developing control system software, application design for various machines accounts for 70%, while developing the connection interfaces between machines accounts for 30%. Furthermore, in the field of Process Automation (PA), when it is desired to transmit all process data from a Distributed Control System (DCS) to the production management system, specific interfaces must be developed for each model from each supplier. For example, applications may be designed using C language DLLs (Dynamic Link Databases) to connect to DDE (Dynamic Data Exchange) servers or using FTP (File Transfer Protocol) text interfaces. For example, a system consisting of four control devices and three connected applications (monitoring, trend charting, and reporting) requires significant time to develop interface software for each of the devices (A, B, C, and D), necessitating the use of 12 different drivers. Furthermore, the coexistence of various drivers within the system complicates maintaining the stability and reliability of the operating environment. OPC, on the other hand, was proposed to standardize software interfaces between devices and applications from different vendors, simplifying data exchange. As a result, it provides users with process control software components that can be freely combined and used, independent of specific programming languages ​​and environments. A system utilizing OPC consists of an OPC server that provides data acquisition services according to the application's (client's) requirements, the necessary OPC interface for using the OPC server, and the OPC application receiving the services. The OPC server is developed for the hardware of various vendors, allowing it to accommodate differences in hardware and systems, thus achieving a hardware-independent system configuration. It also utilizes a data type called Variant to provide data in formats required by the application, independent of the hardware's inherent data types. Standardizing interfaces using OPC can create the system shown in Figure 5. As can be seen from Figure 5, users can select monitoring, trend chart, and reporting applications without relying on the internal structure of devices A, B, C, and D or their suppliers. Where is OPC applicable? OPC is a software interface standard connecting data sources (OPC servers) and data users (OPC applications). Data sources can be control devices such as PLCs, DCSs, and barcode readers. Depending on the control system configuration, the OPC server acting as the data source can be a local OPC server running on the same computer as the OPC application, or a remote OPC server running on a different computer. As shown in Figure 6, the position of OPC in the control system can be seen. The OPC interface can be used for HMI (Hardware Management Interface)/SCADA (Supervisory Control and Data Acquisition) and batch processing automation programs that provide raw data from the lowest-level control devices to the data users (OPC applications) via a network, as well as higher-level applications such as historical databases. It can also be used for direct connections between applications and physical devices. Therefore, the OPC interface is a highly flexible interface standard applicable to many systems. The application scope of OPC is shown in Figure 7. The definition of the OPC interface explains that it defines certain component types and determines the performance these components must possess. Such a "service provider" is called an OPC server. A unique OPC server enables connections to existing communication systems. The service users of the OPC server are called OPC clients. OPC clients can be operation and monitoring systems, archiving systems, and many other process data users. This service is manifested through object-oriented attributes and methods. Each OPC server provides program segments for these attributes and methods. Therefore, collaboration between component products from different manufacturers will not be a problem—it's a plug-and-play technology for automation software. In what situations do users need to use the OPC interface? That is, component manufacturers (communication systems, measuring instruments, etc.) that provide process data use the components and the OPC server together. The OPC server can connect to the data source. The communication conversion component with the data source is solely the responsibility of the component manufacturer. Users of the OPC server do not need to concern themselves with the manufacturer's detailed specifications. The OPC interface is application-independent, allowing even traditional office applications to connect to the automation system. Users can choose to install OPC-enabled automation components without worrying about drivers or interfaces, eliminating the laborious and time-consuming task of matching drivers and significantly reducing project costs. To qualitatively assess OPC performance, the selected equipment was tested at Softing. Two commercial PCs were used, configured with Pentium 90 processors and 48 or 64 MB of memory. Lower-end configurations were intentionally chosen to exclude good measurement results attributed to high-performance computers. Both computers ran Windows NT 4.0. For local testing, a small OPC client test application and a PROFIBUS DP OPC server from Softing were installed on one PC. For testing a distributed OPC application involving DCOM, the OPC test client was launched on a second remote PC. Changes in 5000 process variables (a very practical visualization system) were transmitted between the OPC server and OPC client within one second, both locally and between the two computers. For a scenario with only 500 process variables, only 100 milliseconds are needed. Therefore, OPC is considered ideally suited for applications requiring the acquisition of large numbers of dynamic process variables at very short update rates. This is why, aside from products used for process visualization and data acquisition, products like the SOft-PLC 4CONTROL for time-critical control programs are entirely based on OPC. In this configuration, a remote PC is connected to the first PC via the company's intranet. The chosen test is a daily report with event-driven data transmission. The OPC server continuously generates values, which are then transmitted to the OPC client. The test group repeatedly tested the time from the first read of a limited number of data values ​​from the cache of the NT (Network Terminal) interface program to the confirmation by the OPC client after all values ​​have been received. The result is that only the pure server-client transmission time needs to be considered, without considering the time for acquiring values ​​from the automation equipment. Because OPC discards data after it is received by the test client, all specific application processes such as data archiving or visualization are included in the test. The average value is taken from values ​​continuously measured at different times. The numbers transmitted to the OPC client range from 1 to 5000, used to investigate dependence on transmission time. The integrated OPC server, included in the 4CONTROL system, features “zero-engineering” visualization automatically generated from IEC source code and viewable anywhere via a standard Internet browser. If the pre-generated visualizations do not meet requirements, users can use a visualization system software package provided by the SCADA (Supervisory Control and Data Acquisition) manufacturer. Through the OPC interface, 4CONTROL can function as a dedicated OPC server for visualization, which is then used for the entire process visualization system. All variables, function blocks, programs, and tasks in all IEC control programs are displayed as OPC entries/variables in the visualization window; user input is directly transmitted to the control program via the integrated 4CONTROL OPC server. With OPC and 4CONTROL becoming new standards for control programs, hardware with different power requirements can be used in plants with different deviation requirements. The open OPC interface provides customers with a high degree of freedom, allowing them to break free from manufacturer requirements and utilize existing and other advanced technologies with high flexibility. In summary, the use of OPC (OLE for process control) technology has, for the first time, enabled seamless linking between automation control software and hardware without considering driver and interface issues. Based on Microsoft Windows' COM/DCOM technology, OPC defines a manufacturer-independent interface for industrial applications. Even popular Office programs can connect to the world of automation. OPC offers numerous advantages not only to manufacturers of automation components but also to users, giving them unprecedented flexibility in selecting their hardware and software modules. Through standardized communication interfaces, products from multiple vendors can be combined, matched, and interact with each other without program modifications. OPC makes plug-and-play a reality in automation applications and also allows for the integration of a wide variety of fieldbus systems. The numerous advantages of OPC can be summarized as: * Plug-and-play in process control and machine manufacturing industries * OPC makes plug-and-play a reality in automation environments. OPC allows data exchange between hardware devices and application software developed by different vendors through a common interface. Windows technology and the OPC interface make it possible to combine programmable controller hardware and software without developing numerous dedicated communication interface programs, thus saving considerable manpower and resources. *OPC makes access to everything from office products to process data simple, easy, flexible, and reliable.