1. Introduction With the rapid development of networks, more and more industrial control systems are integrating with networks, and many industrial control configuration software programs have also launched network support. Remote data acquisition via networks has become possible and has been applied in some fields. Currently, most remote data acquisition methods use a client/server architecture, requiring the writing of client and server programs and the transmission of data through TCP sockets. While this is an efficient method, it has the following drawbacks: high network requirements; if the network experiences temporary congestion or other minor problems, the system cannot function correctly; manual programming is difficult, generally limiting its use to local area networks; and software must be installed on both the client and server sides. Due to these shortcomings, network-based remote data acquisition has not been rapidly promoted. This paper introduces a remote data acquisition method based on a browser/server architecture. 2. Communication Technology Used in Remote Data Acquisition Ethernet technology has developed rapidly in the nearly 20 years since its emergence, with the advent of 10 Mbps, 100 Mbps, and 1 Gbps networks. Its application areas have also expanded from initial office automation to industrial control and building automation. Ethernet uses the TCP/IP protocol, a cross-platform communication protocol that can be used in both local area networks (LANs) and wide area networks (WANs), facilitating interconnection between heterogeneous machines. For these reasons, in fields such as building automation and industrial control, network integration often involves using Ethernet as the backbone, with fieldbuses or RS-485 buses connecting front-end devices. This allows for complementary advantages, making network integration applications more flexible and convenient. Socket supports connection-oriented and connectionless programming models, as shown in Figure 1. [img=347,300]http://www.ca800.com/maga/images/2003101616515398565.gif[/img] Figure 1 [img=450,259]http://www.ca800.com/maga/images/2003101616523991408.gif[/img] A brief introduction to the various system call structures and important function calls of the programming model follows. The following are important function call formats and explanations, as shown in Figure 2. (1) Create a socket — socketcreate() Call format: socketid = socketcreate(ntype) Explanation: The return value socketid is an integer, i.e., the socket number; ntype: type, which refers to the service protocol type (tcp or udp) desired by the application that created the socket. (2) Specify local address — bind() Call format: bind(socketid, localip, localport) Explanation: localip, the local socket address; localport, the local port. (3) socketlisten() Call format: socketlisten(socketid) Explanation: Used for connection-oriented servers, indicating that it is willing to accept connections. (4) Establish connection — socketaccept() Call format: socketaccept(socketid, &dwremoteip) Description: dwremoteip: pointer to the client socket address structure (5) Send data — socketsend() Call format: socketsend(socketid, *pby, nlen) Description: pbyn: pointer to the send buffer, nlen: buffer size (6) dsockopen(), dsockclose() Description: These two are called directly to open and close the socket library, respectively. (7) socketdestory(socketid) means to release the socket identified by socketid. Since a B/S model is adopted, the client accesses the server through a browser. Therefore, only some important statements of the server-side socket program source code are given below: // Initialization if (dsock_open() == false) { printf("unable to initialize socket library"); return 1; } // Create socket socketid = socketcreate(tcp_socket); if (socketid == invalid_socket) { printf("socketcreate() error"); dsockclose(); return 1; } // Specify local address if (socketbind(socketid, 0l, port) == false) { printf("socketbind() error"); return false } // Wait for connection acceptance if (socketlisten(socketid) == false) { printf("socketlisten() error"); return false; } // Establish connection with the client requesting communication if (socketaccept(socketid, &dwip)) {datacollect(); //Data acquisition omitted} 3 Use of fieldbus technology in remote data acquisition Under the current trend of fieldbus products developing towards open fieldbus technology, we have developed a fieldbus measurement and control network based on Lonworks technology and conforming to the Lontalk protocol, which is particularly suitable for national defense engineering, intelligent buildings, and factory automation. This network fully utilizes Lonworks' existing mature and advanced technologies and convenient development methods, thus possessing the following outstanding features: It offers network products with both high-speed 1.25 Mbps and low-speed 78 kbps communication speeds; it supports multiple communication media (twisted pair, power line, wireless fiber, etc.); it boasts long communication distances, reaching up to 2700m at 78 kbps without repeaters, a performance indicator difficult to achieve with general communication technologies; it supports multiple network topologies; the Lontalk protocol encapsulates all seven layers of the OSI reference model, facilitating upper-layer application development; the Neuron chip internally encapsulates three CPUs, making the application CPU and communication CPU functions relatively independent, simplifying applications, and ensuring greater communication reliability; the communication network is electrically isolated, guaranteeing its security and reliability. The data acquisition and control tasks of the 893-lm measurement and control network are all completed by intelligent front-ends with various functions. To enable these general-purpose intelligent front-ends to complete the required tasks in different measurement and control systems, corresponding settings must be configured for the front-ends. The content downloaded to the front-ends is called the commands or configurations for the front-ends. The host computer operates the front-end by calling the API functions provided by the 893-LM network driver. The driver provides support for Windows/NT user programming, and these functions are encapsulated in a DLL library. During driver installation, the DLL library is automatically installed into the selected driver folder. The main functions supported by the 893-LM network card and the front-end include: network card communication port address setting function (lmport), front-end information reading function (lmtype), switch quantity status acquisition function (lmstate), analog quantity value acquisition function (lmnum), command sending function (lmcmd), program ID and chip ID reading function (lmids), and channel mode reading function (lmmode). 4. Dynamic Web Page Technology and Remote Data Acquisition The World Wide Web (WWW) uses Hypertext Markup Language (HTML) as a means of expressing information. A WWW server stores homepages written in HTML. Users access the WWW server through a web browser (Internet Explorer or Netscape, etc.), retrieve the homepage, and display it after the browser interprets it. This is the basic working principle of the WWW. Ordinary HTML only supports static text, images, etc., meaning that when you visit a website, the page you see remains unchanged. This significantly limits user interactivity. To overcome this deficiency, dynamic web pages emerged, such as those using Java, CGI, and ASP. Dynamic web page technology is generally implemented by programs running on the server side, that is, different HTML web pages are generated through programming and sent to the user's terminal by the server. Dynamic web page technology is currently widely used in processing user orders and receiving data queries. To achieve the goal of remote data acquisition using a regular web browser, we must also use dynamic web page technology. Because server-side programs are written in C language, these programs have hardware access capabilities, thus making it possible to use dynamic web page technology for remote data acquisition. A remote data acquisition system based on a client/server architecture is shown in Figure 3. The user communicates with the server through a client program on the client computer, instructing the Lonworks front-end connected to the server to collect data and send the results to the client. If it is changed to a remote data acquisition system based on a browser/server architecture, the client computer uses a regular web browser to issue acquisition commands and view data. [img=450,141]http://www.ca800.com/maga/images/2003101616541096396.gif[/img] In fact, server-side programs based on dsock are easy to write. This is because it doesn't include a user interface; all data acquisition is handled by the acquisition subroutine, input commands are automatically obtained from the client by the server, and all output is automatically sent to the user's browser by the server, with the browser responsible for interpreting and displaying the data. Its execution flow is always a simple command read-process-output. (See Figure 4) Input and output follow established dsock rules, while the processing stage has no restrictions. dsock is based on the DOD (Department of Defense) model, providing the dsock.lib library, a DOS TCP/IP library that provides a network service interface for users who need to program network applications in a DOS environment. This library provides C language function calls for users to create internet applications, as mentioned earlier. The structure of dsock in the DOS environment is shown in Figure 5. [img=450,281]http://www.ca800.com/maga/images/2003101616533761789.gif[/img] Figure 4 [img=412,300]http://www.ca800.com/maga/images/2003101616544779268.gif[/img] Field data is obtained by directly accessing the hardware or calling the driver. The flexibility of the C language allows for efficient execution of the data acquisition process. The server organizes the acquired data into an HTTP stream and sends it to the server according to the specified requirements. HTTP is a high-level protocol built on top of TCP/IP. Because HTTP does not use persistent connections, this acquisition method is not suitable for continuous acquisition. Only one set of data can be obtained from a single acquisition request, which greatly limits its application scope. To solve this problem, a client-side approach can be used. That is, a timed refresh function is inserted into the webpage, which sends a new acquisition command to the server every certain period of time to obtain new data. There are two methods for refreshing: one is to refresh the entire webpage, and the other is to update the partial content of the webpage periodically by writing a script (using VBScript or JavaScript). 5. Application Examples Our developed monitoring platform consists of one server and four microcomputers connected via Ethernet. The server is equipped with four Lonworks network cards, meaning it can have up to four Lonworks channels, each capable of connecting up to 16 893-LM intelligent monitoring and control front-ends (see Figure 6). The entire system is a browser/server (B/S) architecture. The server is responsible for data acquisition and storage, and page storage; the four microcomputers act as clients, mainly providing the interface for data display, monitoring operations, and command sending. [img=447,300]http://www.ca800.com/maga/images/2003101616551743936.gif[/img] The server uses a DOS-based 386 module, which raises the issue of DOS-Windows network communication. In terms of software, we used TCP/IP, specifically designed for DOS, which effectively solved the network communication problem. In fact, we successfully implemented functions that are easier to achieve under Windows (such as FTP, HTTP, Telnet, etc.) in the DOS environment, and compared with Windows, it has a better cost-performance ratio when completing less complex tasks. The following uses TCP communication as an example (see Figure 7) to illustrate the communication between DSock and Winsock. [img=382,300]http://www.ca800.com/maga/images/2003101616564171497.gif[/img] Communication between the server and client uses a connection-oriented socket programming model. On the server, we used Borland C3.1 to write a server communication program to complete the data transmission between the server and the client over the network. (See Figure 8 for the communication program flowchart.) The data acquisition part is specifically completed by the server-side data acquisition program. Startup and Operation Process: After the server powers on, it automatically starts the timed data collection program and the HTTP protocol service program, entering a communication waiting state. The client connects to the server through a browser, accesses the requested page, and the webpage refreshes periodically (e.g., every 1 second), requesting services from the server. The server responds to the client's request, receiving data from the client and placing it in the buffer data area. Simultaneously, it sends the requested buffer data area to the client for data refresh and display. 6. Conclusion Remote monitoring using dynamic web page technologies such as ASP is feasible. In practical engineering, it achieves the goal of remote data collection/monitoring using a common web browser. This browser/server-based data collection/monitoring method has advantages such as easy development and simple debugging, making it suitable for applications where real-time requirements are not high. This method can also be easily ported to the Internet, greatly expanding the scope of remote data collection and monitoring.