This paper introduces the design of an embedded network monitoring system based on a client/server model, suitable for industrial applications. The server uses a 32-bit Freescale ColdFire MCF5272 CPU and mClinux as the operating system. The client can be any PC on the network with client software installed. The monitoring interface is designed by the client and can be upgraded to meet new monitoring tasks. This system boasts strong versatility and flexibility, facilitating secondary development by users. I. Introduction Currently, embedded network monitoring systems have become a hot topic in the industrial control field due to their small size, multiple functions, and support for Ethernet technology. Network monitoring systems can be divided into two types: B/S (Browser/Server) and C/S (Client/Server). For the B/S model, the embedded server requires a sufficiently large memory capacity. Furthermore, for applications where the monitoring equipment structure is frequently adjusted or the monitoring content is frequently changed, modifications to the web pages and CGI programs on the embedded server are necessary. This undoubtedly poses significant difficulties for ordinary users when maintaining and developing the server. The system design using a C/S architecture introduced in this paper overcomes these problems. Since the client machine handles both the configuration of the monitored objects and the monitoring page, the server only needs to collect data, respond to client requests, and send client request data via TCP/IP network. Furthermore, the client's monitoring page uses a generic Microsoft Windows style, reducing the requirements for operators and facilitating secondary development. II. Overall Framework of the Embedded Network Monitoring System Taking the monitoring of PLCs and CAN bus devices in factory production automation as an example, to achieve transparency in factory production, it is desirable to monitor production status from anywhere via the network and to be able to change the monitoring content as the factory's production content adjusts. Therefore, a client/server (C/S) architecture can be adopted, allowing the client to define the monitored objects and monitoring page according to specific requirements. The server consists of a 32-bit Freescale Coldfire series MCF5272 chip supporting network communication and the mClinux operating system dedicated to microcontrollers. The system involves a client issuing monitoring commands to the devices. An embedded server receives and processes the information, issuing control commands to the monitored objects based on the client's requests, or obtaining the client's desired status via serial port and CAN interface. This information is then returned to the client via network protocol. The client analyzes the information and establishes an animated connection with the designed monitoring interface, or displays the operating status of the field devices on the interface, and stores this information in the client's historical database for user printing or statistical analysis. III. Client Software Design The client system's tasks are to design the monitoring interface and execute monitoring tasks. Therefore, the client software has two functional modules: an interface development environment and an interface runtime environment. This system uses configuration software developed with VC6.0. Clients can customize the monitoring interface style or collaborate with domestic configuration software manufacturers to design universal client interface software. The interface development environment in the client software generates the human-machine interface for monitoring. The development environment should provide the objects needed to construct the field screen, such as lines, filled graphics, text, and directly callable graphic libraries. For meaningful graphical runtime interfaces, a conversational dialog box will be provided to establish an animated connection between these graphics and the field control units. After a user customizes the monitoring interface through the development environment, the development environment creates a series of data files based on this interface and generates the final graphical target application file for use by the runtime environment. The runtime environment loads the target application file generated by the development environment into memory and puts it into real-time execution, typically accomplished by multiple threads. The interface execution thread receives user request events and sends the user's requests to the uplink/downlink message queues in the runtime and memory according to a specific data format. The real-time message management thread manages the message queues and sends and receives data. To accommodate the diversity of monitored objects, when the message sending thread sends user messages to the server, it organizes the messages according to the communication protocol of the monitoring device at the monitoring device protocol interpretation layer, based on the monitoring PLC type provided by the development environment. This method allows for convenient monitoring of various devices. Simultaneously, the driver is provided in the form of a dynamic link library, facilitating system upgrades. IV. Embedded Server-Side System Design The embedded server adopts a 32-bit Freescale Coldfire series MCF5272 with the mClinux micro-operating system. The 5272 is an embedded chip manufactured by Freescale based on the 68K second-generation Coldfire core, suitable for industrial applications. It integrates an Ethernet interface and has a processing speed of 66 MIPS. Many operating systems can run on the Coldfire microprocessor, but mClinux is arguably the most suitable and cost-effective. The main modules of the mClinux system running on the server side in this system include TCP/IP protocol, PPPoD module, Ethernet port, CAN driver, and serial port driver. The application program includes a PPP dial-up server module and a service program that responds to client requests and communicates with the controlled object via network communication. When compiling the mClinux kernel, necessary components must be added. The application program is compiled using a cross-compilation method, compiled on a PC running REDHAT 9.0 using the Freescale Coldfire series dedicated compiler, and then downloaded to the server's FLASH. In the Ethernet receiving and PLC communication driver, the server continuously listens to the network port, receives messages from the client via network communication, and forwards them to the serial port connected to the PLC. The request message sent from the client to the server is defined as a request message conforming to the communication protocol of the monitored object. This allows the server to connect to any system-supported device without needing to configure the monitored object type, as this task is already completed by the client during interface design. The PPP server daemon is primarily used when the client establishes a network connection via dial-up through a modem and telephone network. V. Network Communication and Redundancy Technology The TCP/IP network communication programming method between the client monitoring interface (running on the Windows operating system on the client machine of the monitoring system) and the embedded server uses BSD Socket interface programming. Through this, network endpoints (IP addresses and port addresses) appear in the form of sockets. This socket IPC (inter-process communication) method is designed to allow the network program design to be independent of different underlying communication infrastructures. In this system, Socket communication between the client and server occurs in a heterogeneous environment; the client uses WinSocket, and the server uses Linux Socket. To ensure smooth communication, in addition to using Ethernet ports for communication, serial ports and modem dial-up are also provided as redundancy for establishing communication links with the remote server. To implement modem dial-up connections, dial-up software must run on the client side, and a dial-up server program must run on the server side. Clients can use the dial-up software that comes with Windows, while the server must run a dial-up service monitoring program in the background. Dial-up communication uses the PPP point-to-point protocol, which is included in mClinux. The PPPD protocol routines provide LCP (Link Control Protocol), user authentication, and IPCP (Internet Protocol Configuration) for PPP connections. The working mechanism of the dial-up server daemon running on the embedded server is as follows: It configures and opens the serial port, sending AT commands to check for the presence of an external modem. If the modem is normal, it sets the automatic answer mode using standard AT commands, then enters a serial port input detection loop. When a ring stream is received from a remote modem (i.e., the serial port receives the RING character), the software forces the phone to go off-hook and enters the physical link establishment phase. After a successful connection, the serial port displays the CONNECT character. At this point, the program vfork a process, starts PPPD, and enters the PPP connection phase to handshake and negotiate the protocol with the dial-in client, perform user authentication, configure the remote computer's IP address, and establish a PPP connection. After a successful connection, PPPD modifies the routing table of the mClinux system to add a new directly reachable route path, enabling network communication between the client and the embedded server via serial port IP packet sending and receiving. VI. Conclusion This paper introduces a monitoring system with a 32-bit CPU and mClinux operating system embedded solution on the server side. This facilitates device miniaturization. The client/server architecture allows for client-side monitoring interface design, and the system is independent of the monitored objects. Drivers can be added by upgrading the client software to meet new monitoring tasks. This design pattern increases the system's versatility, flexibility, and product lifecycle, and facilitates secondary development by users. With the increasing penetration of embedded network devices into industrial production and various monitoring applications, this system has a promising future.