Abstract: Based on a brief introduction to OPC technology, this paper describes the structure and development steps of an OPC server, and details the implementation of OPC technology in a CAN bus system. Keywords: OPC, OPC server, COM, Fieldbus 1 Introduction to OPC Technology 1.1 What is OPC? OPC (OLE for Process Control) is an object linking and embedding technology for process control. It is a specification and a hardware and software interface standard used in industrial control and production automation. Based on Component Object Model and Distributed Component Object Model (COM/DCOM) technology, OPC adopts a client/server model and defines a set of COM objects and their interface standards. The OPC specification was developed by leading hardware and software developers in the automation field worldwide in collaboration with Microsoft, and has gained increasing recognition from customers and hardware manufacturers. 1.2 Significance of OPC In traditional control systems, for the same hardware device, each application software must develop its own hardware driver according to its needs. This not only increases development and maintenance costs, but also brings access conflict problems. OPC technology encapsulates the drivers and communication programs of various hardware devices into independent OPC servers. Upper-layer application software (as OPC clients) can access the OPC server through the standard OPC interface without caring about the performance characteristics of the hardware. This not only solves the above problems, but also realizes the "plug and play" of the software. OPC is equivalent to a software "motherboard". It can directly connect with the PLC, industrial network, data acquisition and Windows CE devices in the field to quickly and effectively obtain real-time data in the field. Various monitoring, control and management application software in the PC are like software "chips" plugged into the OPC motherboard. The chips can obtain real-time data in the field through OPC, and the chips can also communicate with each other according to the OPC protocol, thereby realizing the "plug and play" of the software. 1.3 OPC objects and interfaces The core of OPC is COM/DCOM technology. In the COM model, the functions of the software are decomposed into some components. These components are connected under certain conditions through the COM protocol to realize the corresponding functions. COM objects are divided into two categories: clients and servers. Clients access servers through the COM interface [2]. The OPC data access specification describes the COM objects and their interfaces that the OPC server needs to implement. It defines a custom interface and an automation interface [1]. OPC client programs communicate with the server through the interface and indirectly read data. The OPC server must implement the custom interface, or it can selectively implement the automation interface. Generally speaking, the automation interface can provide great convenience for high-level language client programs such as VB, but the data transmission efficiency is low; while the custom interface provides flexible and efficient calling methods for programs written in C/C++. When the OPC client program accesses the server, it creates a server object (here referring to a logical object, the purpose of which is to use this logical object to establish a connection with the actual server), calls the interface of this server object, the server object creates a group object and returns a pointer to the group object, and the client program calls its interface after obtaining the pointer to the group object. Note that the OPC item is not the object that the OPC client directly operates on, because the OPC item does not define an external interface, and all operations of the object are performed through the group object that contains the item. 2. Structure and Design Steps of the OPC Data Access Server 2.1 Structure of the OPC Data Access Server [align=center] Figure 1 Structure of the OPC Data Access Server[/align] The OPC data access server implemented in this paper has data acquisition capabilities and provides a customized interface conforming to the OPC specification. It mainly consists of an OPC server object, OPC group objects, OPC item objects, and an I/O dynamic link library (DLL) written for CAN (Controller Area Network) communication cards, adopting the structure shown in Figure 1. The OPC server object is the primary object for client-server interaction. The client interacts with the server object by accessing its interface functions. A server object can contain more than one group object. The main functions of the OPC server object are: ① Creating and managing OPC group objects; ② Managing the server's internal status information; ③ Translating server error codes into descriptive statements; ④ Browsing the server's internal data organization structure. The OPC group object is used to organize and manage the server's internal real-time data information; it is a collection of OPC item objects. Because of the group objects, OPC applications can access the required data in batches, and can also start or stop data access in groups. Its main functions are: ① managing the state information within group objects; ② creating and managing item objects; ③ providing real-time data access services (synchronous or asynchronous) within the OPC server. The interfaces supported by OPC server objects and group objects are defined by the OPC specification, but the specific implementation is not specified and needs to be completed by the developers themselves. An OPC item corresponds to a module in a field device; it contains the value, quality, and timestamp of the data item. An I/O DLL is a driver developed for a specific hardware device, implementing the function of reading data from the field device. 2.2 Main steps for implementing an OPC data access server: 2.2.1 Obtaining and registering OPC standard components. According to the COM specification, COM servers can be divided into in-process servers, local servers, and remote servers. The latter two types of servers run in different process spaces than the client program and belong to out-of-process servers. To achieve inter-process communication, a proxy/stub module is needed. The proxy/stub module is directly generated by the Interface Description Language (IDL). The OPC Foundation provides corresponding proxy/stub dynamic link libraries for each type of OPC server. These files can be downloaded free of charge from the OPC Foundation website (www.opcfoundation.org). Note that when designing an OPC server, interfaces can be added to OPC objects to meet specific requirements, but the standard OPC IDL file or the corresponding proxy/stub DLL cannot be modified. The description of the new interface should be defined in a separate IDL file, and a separate proxy/stub module should be generated from this file to complete the interface calling work. Component registration will be introduced later. 2.2.2 Writing OPC Server Code First, define the name (ProgID) and class identifier (CLSID) of the OPC data server, implement the initialization function of the COM library and the interface function of the OPC data server class object. Then implement the OPC object and data buffer. Next, write an I/O DLL for specific hardware to realize real-time data reading. This work is very arduous and requires developers to have good COM programming knowledge. The specific process cannot be detailed due to space limitations. Here, two points are noted: ⑴ Globally Unique Identifier (GUID) The GUID is a sixteen-byte identifier provided for each COM object. A COM class has at least two GUIDs: a class identifier (CLSID) and an interface identifier (IID). The CLSID identifies the COM class, is registered in the Windows registry, and contains the path to the DLL or EXE component that includes the COM class. The IID identifies the interface of the class, is used by applications to query and trigger the class's methods, and is also registered in the registry. Because object classes are identified by GUIDs, their uniqueness must be guaranteed to prevent conflicts when end users use components developed by different software vendors. The macro `DEFINE_GUID(name, long, word, word, word, byte1, …, byte8)` can be used, where `name` is the name of the identifier, and the remaining parameters are the actual ID code. The naming convention for class identifiers is `CLSID_ClassName`, while the naming convention for interface IDs is `IID_InterfaceName`. There are two ways to obtain a GUID: ① Microsoft Visual C++ provides two tools to generate GUIDs: `UUIDGen.exe` and `GUIDGen.exe` (case-insensitive). The former is a command-line program that directly generates a GUID; the latter is a dialog-based application that runs UUIDGen.exe and generates a Create GUID dialog box. It provides four formats; after selecting one, pressing the New GUID key generates a new GUID, which is displayed in the Result column; pressing the Copy key copies the result. ② Using API functions provided by the COM library to generate a GUID: HRESULT CoCreateGuid (GUID *pguid) If the GUID creation is successful, the function returns S_OK, and pguid will point to the obtained GUID value. ⑵ The OPC component registry is an information repository accessed by both the client and the component program. Normally, after a component program is installed on a computer, it must register its information in the registry through some means before the client program can operate on the component program based on the information in the registry. According to the COM specification, component programs can be divided into self-registering component programs and non-self-registering component programs. Components provided by the OPC Foundation are all self-registering components. For non-self-registering component programs, the registration process is not directly related to the component program itself; the registration information must be configured separately. For example, a registry file can be created and then imported into RegEdit. For in-process self-registering components in DLL form, Windows provides the RegSvr32.exe registration tool for component registration and unregistration. The component program itself must contain two registry entry functions: DllRegisterServer and DllUnregisterServer. The registration and unregistration formats are: RegSvr32 <system path> RegSvr32 /u <system path> For out-of-process self-registering components in EXE form, the COM specification stipulates that two command-line parameters, /RegServer and /UnregServer (case-insensitive, and "/" can be replaced by "-"), must be supported to complete the registration and unregistration operations. The registration and unregistration formats are: <system path> /RegServer <system path> /UnregServer 2.2.3 Testing the OPC Server After debugging, the OPC server needs to be tested using an OPC client program to verify its main functions. 3 Application of OPC Technology in CAN Fieldbus Systems The OPC server developed in this paper is designed for Huakong Company's CAN communication card and is used to read information from the field communication network composed of Huakong's CAN communication card and RSM intelligent module. 3.1 System Composition The system mainly consists of a host computer, CAN communication card, OPC client, OPC server, RSM intelligent module, and communication media, as shown in Figure 2. [align=center] Figure 2 System Composition[/align] ① Host computer hardware and software configuration: Microsoft Windows 98/2000 or Windows NT operating system; 32MB or more of memory, 1GB or more of available hard disk space, and SVGA display card. ② The CAN communication card used is the HK-CAN30B from Huakong Company. It is a non-intelligent CAN card that connects the CAN communication protocol to the PCI bus standard of a PC. This card can be used to monitor instruments and control equipment with CAN communication interfaces in the industrial field. ③ The CAN field devices use Huakong's RSM intelligent module. Each module works periodically under the management of an embedded real-time multi-tasking kernel, sending and receiving data periodically according to configuration requirements. ④ The communication media can be twisted pair cable, shielded twisted pair cable, etc. ⑤ The client uses Likong Company's Likong 2.6 monitoring and configuration software. Likong 2.6 supports OPC technology. As an OPC client, it fully utilizes the powerful performance of the OPC server, providing engineers with convenient and efficient data access capabilities. Multiple OPC servers can be connected simultaneously in ForceControl, and each OPC server can be defined, added, or deleted as an external device. 3.2 Connection between OPC Server and Client 3.2.1 Defining the OPC Device First, in the ForceControl navigator window, select "Real-time Database" and expand "I/O Device Driver" to reveal the "OPC" device. Double-click "OPC (Client)" to open the I/O device definition dialog box. Define the logical device name in "Device Name" (user-defined), for example, "OPC". Specify the acquisition cycle in "Data Update Cycle", fill in the recovery query cycle and maximum time after a failure, and then click "Next" to open the OPC device definition dialog box. ForceControl will automatically search for all installed OPC servers in the computer system. If the OPC server is correctly configured and registered, clicking the "OPC Server" dropdown will list the names of all installed OPC servers. Select the OPC server to use; here, we select the server "OPC.Server.1" designed in this article. Select "Server Type" and choose between "Local" and "Remote". In "Data Access Method", select "Buffer" or "External". For "Buffer" mode, the OPC client program will read data through the OPC server's buffer; for "External" mode, the OPC client program will read data directly from the device through the OPC server. Reading data directly from the device is slower and is generally only used in fault diagnosis or very special cases. Enter a percentage value in "Dead Zone Percentage" to indicate that data will not be updated if the change in process data value does not exceed this percentage. Click "OK" to complete the OPC device definition. 3.2.2 Connecting OPC Data Items Start the ForceControl database configuration program DBMan. First, create the variable to be used in the point configuration, let's call it gg1. Expand the "Data Connection" item; the already created OPC devices are listed there. Double-click the OPC device "OPC" we just created, and the "Data Connection" dialog box appears. Select the point parameter gg1 to connect to, and click the "Add" button to display the "Data Item Configuration" dialog box. If the OPC server supports the "Browse" function, double-clicking "Root" in the upper right list box will automatically list the data area it provides. If the OPC server does not support the "Browse" function, the description of its data items needs to be manually filled in by the user in the "Data Item" input box according to the OPC server's documentation. Select "Data Type" and "Read/Write Permissions," and enter the data access path in "Access Path" (this is not required; if you need to fill it in, refer to the manual of the OPC server you are using). Do not fill it in here. Finally, click the "OK" button to generate a data connection for a data item, as shown in Figure 3, thus realizing the connection with the actual information on site. [align=center] Figure 3 ForceControl Data Connection Result[/align] During system operation, ForceControl establishes a connection with the server and automatically completes data exchange with the OPC server. 4 Conclusion The OPC data access server designed in this paper conforms to the OPC specification, realizes real-time data reading and writing, and has practical value. In summary, with the OPC standard, control system software can efficiently and stably access data from hardware devices, and system application software can flexibly exchange information, greatly improving the interoperability and adaptability of the control system. References: 1. OPC Foundation. Data Access Custom Interface Standard, Version 2.05A, 2002. 2. Pan Aimin, COM Principles and Applications, Tsinghua University Press, December 1999.