Introduction With the increasing safety awareness and improved modern management levels of various enterprises, remote monitoring and control of distributed environments is being increasingly widely used in industrial control systems. Traditional monitoring systems often involve a remote monitoring host interacting with a proxy server via a transmission network. This method requires additional data acquisition and control equipment to collect data from field devices and send the collected real-time data to the proxy server. It suffers from poor adaptability, low intranet data transmission rates, affecting the real-time performance of remote monitoring, and when the proxy server fails, the remote monitoring host loses monitoring and control over all field devices, resulting in low reliability. Therefore, this paper proposes a remote centralized monitoring and control system based on embedded technology. This system organically combines embedded technology, wireless communication technology, and automatic control technology, employing an embedded hardware platform and wireless communication modules, eliminating the need for additional data acquisition and control equipment. This system boasts strong real-time performance, high reliability, compact structure, and low development costs, making it more suitable for modern industrial monitoring and control systems. 1. System Overall Design Scheme The implementation scheme of the embedded remote monitoring and control system is shown in Figure 1. The system consists of three parts: a client browser, an embedded server platform, and a field monitoring and control module. The client browser is a general-purpose browser application running on a desktop computer. The embedded server is a network service platform built around the S3 C4510B chip, and the field measurement and control module is a measurement and control execution component built around the MCS-51 microcontroller. The embedded server platform is the core component of the system, responsible for acquiring, storing, forwarding, and interacting with remote client browsers on the field devices' measurement and control data. Figure 1 shows the implementation scheme of the embedded remote centralized control system. In this scheme, the server uses an embedded hardware platform based on the uClinux operating system to establish an embedded web server and a distributed field measurement and control application. The measurement and control application communicates with the embedded platform and the distributed measurement and control devices through an active polling method via a wireless module. The field measurement and control module is responsible for responding to commands issued by the measurement and control application to complete data acquisition and control action execution in the distributed field. The interface between the embedded web server and the distributed field measurement and control application is implemented through the Common Gateway Interface (CGI). CGI allows the written program to process forms and data sent from clients on the WWW and respond accordingly, standardizing the interface between the written program and the web server. Embedded servers often require a file system to function properly, and the uClinux operating system provides an excellent file system. Furthermore, utilizing the built-in TCP/IP (Transport Control Protocol/Internet Protocol) stack of uClinux, server-side programs can be written only at the application layer using the network APIs (Application Programming Interface) provided by the operating system, significantly saving development time. 2. System Hardware Design For an embedded system, hardware system design is crucial. On one hand, it's essential to consider whether the selected components are suitable for the application requirements and whether hardware resources are sufficient for programming, debugging, and ensuring excellent system performance. On the other hand, hardware resources should be allocated to minimize costs while meeting system requirements. Based on the S3C4510B core chip, necessary Flash, SDRAM (Synchronous Dynamic Random Access Memory), network interface, and wireless communication interface modules were added. The network transmission interface consists of an Ethernet physical layer interface DM9161, a network isolation transformer FC-1, and an RJ45 interface. This system does not use a separate Ethernet controller because the S3C4510B has an embedded Ethernet controller supporting a Media Independent Interface (MII) and a Buffered DMA Interface (BDI), providing 10/100 Mbit/s Ethernet access in half-duplex or full-duplex modes. In full-duplex mode, it supports the IEEE 802.3 MAC (Media Access Control) layer protocol. The DM9161 handles the physical layer and data transmission/reception functions, supporting 100BaseT and 10BaseT networks. Since the S3C4510B already has an on-chip MAC controller with an MII interface, and the DM9161 also provides an MII interface, and the definitions of various signals are clearly defined, the connection between the DM9161 and the S3C4510 is relatively simple. The signal transmitting and receiving ends should connect to the transmission medium via a network isolation transformer FC-S15IS and an RJ45 interface. Data communication is accomplished using the PTR2Q00 wireless data transmission modem module. This device is a highly regarded wireless data transmission product in the industry. It integrates data reception and transmission; employs FSK modulation/demodulation technology for direct data input/output with strong anti-interference capabilities; utilizes DDS (Direct Data Synthesis) + PLL (Phase-Locked Loop) frequency synthesis technology, resulting in excellent frequency stability; its operating frequency is stable and reliable, with few external components, extremely low power consumption, and ease of design and manufacturing. Furthermore, due to its low transmit power and high sensitivity design, it meets wireless regulatory requirements and does not require a license, making it an ideal choice for low-power wireless data transmission. By using the GPIO of the S3C4510B chip to control the DO, DI, and TXEN pins of the PTR2001, and controlling TXEN by setting the high and low levels of the GPIO, a transmit/receive conversion is achieved. By driving the GPIO (General-Purpose U0 Port) to simulate the DO and DI transmit/receive timing of the PTR2000, and following a multi-machine communication protocol, active data communication can be completed. Furthermore, at the equipment site, the MSC-51 series microcontroller can be used to control the PTR2000 to complete the functions of the field measurement and control module (including the establishment of wireless channels). The TTL level of the MSC-51 is the same as that of the YTR2000, and the DO and DI pins of the PTR2000 can be directly connected to the RXD and TXD pins of the MSC-51. As shown in Figure 2, the connection circuit diagram of the MSC-51 and PTR2000 for field measurement and control connects the Pl.7 pin of the MSC-51 to the TXEN pin of the PTR2000 to control the module's transmission control, channel switching, and low-power mode. Figure 2 Connection circuit diagram of the MSC-51 and PTR2000 for field measurement and control. 3. Software Program Implementation The software program writing in this design involves many key technologies, including an embedded HTTP (Hypertext Transfer Protocol) server, a public gateway interface (CGI), HTML and Java Applet technologies, and inter-process communication under Linux. An embedded HTTP server operates on a client/server model, with a daemon listening on port 80 to provide services. For the embedded HTTP server, the browser acts as the client. Building an embedded HTTP server under Linux-like environments involves network socket programming. Sockets establish communication connections between processes using the client/server model. For an embedded HTTP server, when a service is provided, there must be both a service process and a client process. Before communication, they must create their respective sockets and establish connections before performing "read" and "write" operations on the corresponding sockets to achieve data transmission. The Common Gateway Interface (CGI) is a software module built within the HTTP server that can execute programs stored on the server. CGI scripts, along with the HTTP server, are responsible for responding to client requests. The HTTP server calls the corresponding CGI program based on the request, processes it, and finally returns the processing result to the client, ending the interaction. Traditional plain HTML documents contain static information, while CGI scripts can run in real-time based on user requests, generating dynamic information with high efficiency and greater flexibility. HTML implementation is relatively easy, while Java Applets are more complex. This system's Java Applet consists of two parts: a graphical interface and a network connection interaction. The overall operation of the Java Applet follows the Java Applet lifecycle (including three basic loops: init(), start(), and stop()). For the graphical interface, Java's Abstract Window Toolkit (AWT) contains many classes to support GUI design and establish standard graphical interfaces. Using the basic components provided by AWT, buttons, checkboxes, labels, menus, scrollbars, and text areas can be set; container components can be used to create panels, windows, frames, and dialog boxes; and AWT also provides drawing methods and event handling mechanisms using provided layout managers (such as LayoutLayout, BorderLayout, and GridBagLayout). This system also involves multiple processes. For example, the wireless serial port module management process needs to receive and send data and commands from the serial port, while also returning measurement results to the CGI process. All of this must be achieved through communication between the two processes. In Linux, inter-process communication can be implemented using signals, pipes, and System V inter-process communication (message queues, semaphores, shared memory), etc. Since older versions of uClinux do not support System V inter-process communication (IPC) mechanisms, shared files can be used to facilitate communication between the CGI process and the wireless serial port module management process. To facilitate inter-process communication, a text file named `note.txt` is created. The wireless serial port module management process writes data transmitted from the serial port to `note.txt`, and the CGI process reads data from `note.txt`. However, access to `note.txt` by the two processes is mutually exclusive; that is, at most one process can access the file at a time. Mutual exclusion can be achieved using a file `write.lock`. Before accessing the `note.txt` file, the wireless serial port module management process checks if a `read.lock` exists. If it does, it waits; otherwise, it creates a `write.lock` file lock, then opens the `note.txt` file for access, and removes the file lock after access is complete. Similarly, a `read.lock` file lock allows the CGI process to read data from `note.txt`. When uClinux supports System V IPC mechanisms, message queues, semaphores, and shared memory are generally used. Here, a combination of semaphores and shared memory is used. Shared memory is a special address range created by IPC for a process, appearing in the process's address space. Other processes can "link" the same shared memory segment to their own address spaces. All processes can access the shared address. If a process writes data to this shared memory, the changes are immediately visible to other processes authorized to access the same shared memory. Shared memory itself does not provide any synchronization functionality; a semaphore is used to synchronize the read and write operations of the program, and its protection mechanism prevents incorrect memory sharing. Figure 3 shows the embedded HTTP server interface index.html. 4. Test Results and Conclusions Based on the above scheme, network application tests were conducted on the implemented embedded remote centralized monitoring and control system. The monitoring and control execution component completes tasks such as acquiring and controlling the temperature display device at the site. Enter http://192.168.0.2/index.html in the browser URL field (192.168.0.2 is the IP address of the embedded HTTP server). The embedded HTTP server index.html interface is shown in Figure 3. Double-clicking "Embedded Temperature Measurement System" brings up the Java Applet interactive interface shown in Figure 4. This interface displays the actual measured temperature curve. Test results show that the design of this embedded remote centralized monitoring and control system is reasonable, with superior reliability, real-time performance, and development cost compared to similar technologies. It also provides a successful reference example for the network application of embedded systems. Figure 4 shows the Java Applet interactive interface. The remote centralized monitoring system based on the embedded system is a comprehensive application of multiple technologies such as data acquisition, network transmission, and computer software. It is suitable for real-time monitoring and automated management of remote field environments, ensuring the safe and stable operation of industrial production. It not only has basic environmental indicator monitoring functions but also connects the control terminal and field devices wirelessly, enabling centralized monitoring, querying, and statistical work on a host computer. It has advantages such as flexible structure, good human-machine interface, and integration of modern control and management technologies, improving production efficiency. This system can also be applied to other long-distance distributed control scenarios.