1 Introduction Industrial control applications have spread to all walks of life. In particular, with the general decrease in the price of computers, there are more and more control systems built by PCs. The advantage of this type of control system is that developers can quickly build their own software systems using high-level languages ​​and a large number of existing software. This article mainly introduces an implementation method for this type of application: the method is to classify all hardware I/O parts by type. All their respective read and write processes are functionalized. After mathematical abstraction, they are normalized into stream objects for unified processing: sensor → stream → (initialization function, stream read, stream write, close) → application software read and write thread → user message → main window. After such abstraction, no matter how complex the control system is or what form the hardware sensor is, it is all processed using a unified software method under this software architecture. ... The main control console communicates with the measuring station via RS-232 and a modem. It connects to other measuring devices via A/D and D/A connection cards, and communicates with the central computer via a network. When constructing the software for this control system, we can expand the problem by assuming we don't consider specific controlled devices or application types, and instead consider a more complex control system: The envisioned control system is shown in Figure 2. The control computer uses a P4 2.8 or P4 2.4 GHz processor, and the specific controlled object can be imagined as an abstract sensor. [b]3 Control System Software Architecture[/b] The software architecture provided in this paper is as follows: For each type of control hardware device, accessing this type of hardware corresponds to the following functions: (1) Hardware initialization function. (2) Hardware read function. (3) Hardware write function. (4) Hardware refresh and close function. Thus, after mathematical abstraction, access to each type of hardware does not exceed these 5 functions. Regardless of what hardware sensors the control system is built with, for a type of sensor, accessing it only requires a few statements. Assume that the relevant I/O functions are compiled according to the type. The main idea of ​​this software system is: any control object (sensor) can be imagined as a stream device, and the thread completes the stream read and write. The read and write timing is determined by interrupts or other device events. Once the hardware device I/O is completed, the data is locked with a critical section and imported into the soft device buffer. The user interaction part only deals with the soft device buffer and is not related to the device hardware. The control function is only responsible for filling the device buffer. This function is only related to the communication protocol and is not related to the hardware device. Thus, any hardware device communicating with the computer can be regarded as the exchange of a stream of information. A simpler view is that any hardware device can be directly considered as a hexadecimal string of a certain length. Thus, any control system within this software architecture represents several hexadecimal strings. The main software framework categorizes these flows into several main types (serial communication, network, etc.). Adding or removing certain hardware components simply disables a few conditional compilation options for the software system. Moreover, for each type of application, there are 4 or 5 I/O functions. All hardware-related parts are completed at the thread level, and the read/write thread structure is completely consistent. The foreground user interaction is completely independent of the background. The background is related to relevant event notifications and has almost no other connection with the foreground. Therefore, after the foreground fills all buffers, it only needs to call one event notification, and the background will automatically wait for the notification and then switch to its own I/O operation. A read thread completes a specific hardware read. The read timing is driven by read events. Once the read thread reads data, the data first enters the user-designed critical section, locking the data. The data read from the hardware buffer is then placed into the software buffer, and a read completion message is sent to the user and the foreground, achieving hardware-software isolation. The write thread completes a specific hardware write operation. The write timing is driven by write events. Once the write thread needs to write data, it first calls the control function to fill the device buffer, enters the user-designed critical section to lock the data, places the write data from the software buffer into the hardware buffer, and sends a user-defined write completion message to the foreground, achieving software-hardware isolation. The user-processed message for read completion is: complete data conversion for display. The user-processed message for write completion is: first inform the user of the status counter, indicating that the write is complete, and then perform other display processing. Access to each hardware component is completely separate, but the read and write thread structures are identical. The form of the control function is also identical, regardless of whether a PID algorithm or other algorithms are used. This is because the essence of the control function is: to fill the abstract software buffer based on the control word. It is unrelated to the control algorithm, as such algorithms are only called as sub-functions within this control function. The function of the control function is: to fill the write buffer based on the control word and set the write length. The fill buffer is a software device buffer, and the structure of the control function is completely uniform for the device. Its form is: where k is the control mode word. For example: 0 is standby, 1 is manual, 2 is theoretical trajectory, 3 is sine trajectory... The control timing is provided by a standard clock device, such as B code or other devices, and the synchronous pulses generated by it are used as interrupt sources to access the system. Once the interrupt handler detects the interrupt, it sets its respective hardware read/write event to signaled (the hardware read/write event is set as a manual reset event by the user during initialization). Once the read/write operation is completed in the read/write thread, these events are reset. Corresponding to the above complex hardware control system, the control software architecture is shown in Figure 3. Read device thread: (1) Determine whether the thread has exited. If it has exited, go to (8); otherwise, go to (2). (2) Wait for the read event, wait forever (this event is a manual reset). This step can be omitted for asynchronous serial devices or network devices. (3) ReadFileDevice() calls the device hardware read function to complete the read operation. (4) Determine whether the read is successful. If it is unsuccessful, go to (1); if it is successful, go to (5). (5) Enter the critical section, copy the hardware read buffer to the soft device buffer, and exit the critical section. (6) Send a user message to the foreground, reset the read event, and prepare for the next read. (7) Go to (1). (8) End. Write device thread: (1) Determine if the thread has exited. If it has, go to (9); otherwise, go to (2). (2) Wait for the write event, wait indefinitely (this event is manually reset). (3) Call the control function to complete the device buffer filling. (4) Enter the critical section, copy the soft device write buffer to the hardware write buffer, and exit the critical section. (5) WriteFileDeivce() calls the device write function to complete the write operation. (6) Determine if the write was successful. If unsuccessful, go to (1); if successful, go to (7). (7) Send a user message to the foreground, reset the write event, and prepare for the next write. (8) Go to (1). (9) End. **4. Conclusion** Under this software architecture, the hardware interface of the control system consists of only 4 or 5 functions from a software perspective. The hardware and software buffers are isolated and synchronized through Windows 2000 kernel synchronization objects (events and critical sections). Control timing is set by setting events via interrupts. After these steps, the computer implementation software structure of the entire control system is clear and easy to debug. This software system architecture is tool-independent. The authors have used this architecture to design multiple control systems, which are currently running successfully in several bases in my country. **References** [1] Cao Guojun, Wang Jian. In-depth Windows 2000 Applications [M]. Beijing: Beijing Kehai Group Press, 2001. [2] Feisi Technology Product R&D Center. In-depth Windows Core Programming under Delphi [M]. Beijing: Electronic Industry Press, 2003. [3] [US] William Boswell. Windows 2000 Server Technology Insider [M]. Beijing: Tsinghua University Press, 2001. [4] Chen Ping, Chu Hua. Software Designer Tutorial [M]. Beijing: Tsinghua University Press, 2004. Editor: He Shiping