Abstract: The Modbus protocol realizes the integration of monitoring data of different operating stations in the cement production raw material system. A general interface component based on the Modbus communication protocol is developed by ATL, so that different stations can be easily interconnected. The network topology and implementation method are introduced, and the integration methods of Modbus and other protocols such as NetDDE and OPC are compared and discussed. Keywords: DCS monitoring data integration Modbus COM Data integration is the key in DCS system. A typical DCS system can be divided into four layers in terms of structure[1]: field level, control level, monitoring level and management level. This paper discusses the monitoring level. There are many parallel substations in this level. Generally, a computer is used as the machine interface. Each station can be divided according to function to collect the corresponding field signals and control some local equipment. However, the stations are not isolated. They must cooperate and coordinate with each other to ensure product quality and achieve continuous production. This requires the stations to be able to communicate with each other. In addition, the upper management network also needs to interact with the monitoring level substations to realize global monitoring and optimization. However, the substation is a heterogeneous system composed of different development platforms and different communication protocols, which may be developed by different manufacturers and individuals. It is quite cumbersome to write a conversion interface or driver for each protocol, especially when there are many stations and protocols. Therefore, how to effectively integrate data and avoid the emergence of information silos is one of the common difficulties encountered in DCS systems. A better approach is for each station to use standard protocols for data communication, rather than developing a communication interface for each protocol. There are many protocols in this regard, and Modbus is one of them. 1 Introduction to Modbus Protocol The Modbus protocol includes ASCII, RTU, PLUS, TCP, etc., but does not specify the physical layer. This protocol defines the message structure that the controller can recognize and use, regardless of the network through which they communicate [2]. The standard Modicon controller uses RS232C to implement serial Modbus. RS232C specifies the connector pins, wiring, signal level, baud rate, parity, etc., while the Modbus ASCII and RTU protocols specify the structure of messages and data, commands, and responses on this basis, as shown in Figure 1. Data communication uses a Master/Slave approach. The Master sends a data request message, and the Slave, upon receiving a correct message, can send data back to the Master in response. The Master can also directly send messages to modify data on the Slave, enabling bidirectional read/write. Figure 2 shows a typical Modbus application example. Modbus can be used between PICs and PLCs that support the Modbus protocol, between PLCs and personal computers, between computers and computers, between remote PLCs and computers, and between remote computers (connected via a modem). Therefore, Modbus has a wide range of applications. Because Modbus is a de facto industry standard, many manufacturers' PLCs, HMIs, and configuration software support Modbus. Furthermore, Modbus is an open standard, and its protocol content is freely available. Small manufacturers and even individuals can develop Modbus-supported products or software based on the protocol standard, thus connecting their products to Modbus data networks. Therefore, Modbus has a broad application base. In practical applications, RS232, RS485/422, modems with telephone lines, and even TCP/IP can be used for networking. Therefore, Modbus offers a variety of transmission media, which can be selected based on the transmission distance. 2. Specific Applications of Modbus The specific application of Modbus described here is a cement raw meal production quality control system in a certain factory. This system has a total of 5 substations: a calcium-iron analyzer, a four-element analyzer, a material level/slurry plug, a batching scale, and a batching silo. Each substation consists of a computer and related hardware and software, and the control system composition is shown in Figure 3. As can be seen from Figure 3, the system basically consists of two control loops: one loop comprises the calcium-iron analyzer, the batching scale, and the control algorithm, realizing pre-milling fine batching, i.e., online real-time closed-loop control of the raw meal quality exiting the mill; the other loop comprises the four-element analyzer, the slurry plug, and the material level gauge, realizing post-milling blending, i.e., homogenization control of the slurry quality before entering the kiln. The batching silo algorithm plays a role in control, optimization, and network interface in the second loop. Changes in system control parameters are triggered by two events: the results of the calcium-iron analyzer analysis and the results of the four-element analyzer analysis. These two analysis results are obtained from the analysis of samples collected periodically by the user during actual production. Figure 3 also shows that the stations are interconnected, and their collaboration affects the quality of raw material production. Network design must not only achieve data exchange between stations but also consider network flexibility, versatility, and scalability. For example, data source stations should be able to easily add or remove data, there may be multiple target stations, data flow should be bidirectional, and data from all raw material systems needs to be sent to the plant-level DCS, making network implementation complex. Because the Modbus protocol is diverse, reliable, and an industrial-grade standard protocol, it is perfectly suitable for specific applications; therefore, Modbus is used to implement the network. Implementing Modbus using source code at each station is impractical because application development platforms differ, such as Visual C++, making code reuse impossible. However, the operations for reading and writing Modbus data are identical at each station. To address this, we adopt COM technology. COM is also a standard for data communication between software modules. COM is characterized by language independence, time-transparency, and binary reusability. Because its interface is open, client programs supporting COM technology can call the internal functions of COM components through their public interface. As is well known, in Windows 2000, COM+ is even the foundation of the operating system. Finally, two COM components were developed using ATL, namely the Modbus Master component and the Modbus Slave component. ATL is a framework based on C++ simulation technology. It is mainly used in the development of even COM software. Using it can greatly simplify the component development process and improve code efficiency [5]. The Master and Slave components both include ASCII, RTU and TCP modes, and implement the functions specified by Class0 and Class1 [3]. The client program of each substation does not need to know the specific protocol and implementation of Modbus. It only needs to call the methods exposed by the component to exchange data with the remote computer, realizing the transparency of the Modbus protocol and the transparency of network data transmission. For example, for the Slave component, the client only needs to modify its connection data to make the change reflect the Master. After the Master modifies the data, the Slave will trigger an event to notify the client. The network structure does not use point-to-point connection, but adopts star connection. A real-time database is established on a station, which is equivalent to a data center. All stations are only connected to the data center, and the data of each station is also sent to the data center. The network structure is shown in Figure 4. 3. Discussion 3.1 Regarding specific applications In the network structure shown in Figure 4, on the one hand, the system encapsulates the Modbus protocol and network implementation, realizing function reuse, reducing repetitive operations, and making network debugging more convenient; on the other hand, the star topology makes it convenient to add data and stations. In principle, each station can obtain data from any station without adding new connections. Under the network structure shown in Figure 4, the batching bin and batching scale can be easily connected to realize half-bin batching (controlling the batching scale formula based on slurry quality feedback), increasing the control loop to 3. Some real-time data can also be stored in a historical database for long-term preservation and post-analysis retrieval. 3.2 Other characteristics of the Modbus protocol In addition to the wide application mentioned in the introduction, Modbus has other characteristics. The Modbus protocol requires data verification. In addition to parity checking, serial protocols use LRC verification in ASCII mode and 16-bit CRC verification in RTU mode, but TCP mode does not specify additional verification because TCP is a connection-oriented reliable protocol. Furthermore, Modbus uses a master-slave architecture for timed data transmission and reception. In practical use, if a slave site disconnects (e.g., due to a fault or shutdown), the master can diagnose the problem, and the network can automatically reconnect after the fault is repaired. Therefore, the Modbus protocol has good reliability. Modbus defines many functions, comprehensively considering practical industrial applications. Moreover, the protocol is still under development, and users can define custom function codes. Thus, Modbus has good scalability. For some repeatedly transmitted detection data, the Unsolicited method can be used, where the master does not need to send a request, but the slave actively sends the data. This reduces network data traffic and improves transmission speed. Therefore, the Modbus protocol is also quite flexible in application. 3.3 Comparison with NetDDE Protocol The NetDDE protocol has several disadvantages: First, the technology is too old; the Win98 platform only has 16-bit APIs, not 32-bit ones, making implementation on 32-bit platforms difficult, and NetDDE cannot achieve serial connections; second, the data transmission volume is small, and transmitting batch data is cumbersome; third, the connection cannot be automatically restored after being broken. Therefore, NetDDE was not used to implement our network. 3.4 New Direction of Industrial Data Integration OPC is an open industrial specification and standard for data communication between applications. It adopts a client/server architecture and is based on OLE/COM technology, providing a standard interface for hardware manufacturers and application software developers [6]. OPC has an advanced structure, high speed, and powerful functions, and is the future direction of industrial data integration. However, OPC is relatively new, has high requirements for developers, is difficult to develop, and OPC products are relatively expensive. It has not yet been popularized in domestic DCS applications, and its promotion and development still need a process. In summary, Modbus has the advantages of openness, wide user range, easy implementation, good scalability, and strong reliability. Therefore, we adopted the Modbus protocol and COM technology to realize the integration of monitoring data, and achieved good results in connecting with self-developed applications and with DCS systems and HMIs such as FOXBORO, ROSEMOUNT, and CIMPLICITY.