Abstract: This paper introduces a monitoring software suitable for small and medium-sized process control systems. The software is based on the LabVIEW+DSC design method. Practical operation has proven that this method results in a high cost-performance ratio and verifies its feasibility in process control. Keywords: Monitoring software, LabVIEW, DSC module, OPC server 1 Introduction Currently, most devices used for monitoring functions are implemented using commercial configuration software (such as Fix, KingSCADA, etc.). These software programs have certain functional limitations: while they can design user-friendly interfaces, they are charged based on the number of installed nodes and I/O points, resulting in a relatively low cost-performance ratio for small and medium-sized systems. In contrast, LabVIEW offers advantages such as a user-friendly interface, powerful functions, and easy maintenance. Therefore, this paper proposes using LabVIEW as the measurement and control software for the control system in the host computer to realize the process control monitoring function, thus replacing the host monitoring configuration software. A brief introduction follows. LabVIEW (Laboratory Virtual Instrument Engineering Workbench) is an abbreviation for Laboratory Virtual Instrument Integrated Development Platform. It is one of the most widely used virtual instrument development environments in the world. The biggest feature of LabVIEW is that it uses a compiled graphical programming language - G language (Graph Programming). It has similarities with traditional languages ​​such as C, Pascal, and Basic, such as similar data types, data flow control structures, program debugging tools, and modular programming features. However, the biggest difference between the two is that traditional programming languages ​​use text language for programming, and the execution of the program depends on the instructions described in the text; while LabVIEW uses graphical language (i.e., various icons, graphics, symbols, lines, etc.) to write programs in the form of block diagrams. Programming with LabVIEW does not require much programming experience, because LabVIEW uses terms and icons that test engineers are familiar with, such as various buttons, switches, waveforms, etc., and the interface is very intuitive and visual [1]. However, when using LabVIEW to implement accident alarms, system event occurrences, real-time and historical data curve display, and safety functions, they are all implemented through complex programming. Therefore, it is relatively difficult for users who are not familiar with LabVIEW. In view of this, NI has launched an add-on module for LabVIEW - the Datalogging and Supervisory Control Module (DSC). This module is designed specifically for process control. It provides the necessary controls and functional modules for implementing process control software, such as real-time historical trend charts, databases, alarms, data reports, etc. [2]. Therefore, using the "LabVIEW+DSC" design method to develop monitoring software, the above functions are simple to operate and do not require a lot of programming work, saving development time and improving development efficiency. 2 Monitoring Software Design The basic monitoring functions that monitoring software should generally implement include: data acquisition and data processing functions, system fault diagnosis and accident alarm functions, graphical configuration functions, real-time and historical data curve display functions, report printing functions and user-friendly human-machine interface [4]. 2.1 Data Acquisition and Storage In the fieldbus control system, for process control, an important part is to display and query the real-time acquired data and analyze the reports, which involves the issue of data acquisition and storage. "Data acquisition" refers to the process of acquiring analog quantities such as temperature, pressure, and flow, converting them into digital quantities, and then storing, processing, displaying, or printing them by a computer. Therefore, implementing real-time data acquisition using LabVIEW is a key part of the design and research. The software architecture diagram using the "LabVIEW + DSC" combination is shown in Figure 1: [align=center] Figure 1 Software Architecture Diagram of "LabVIEW + DSC"[/align] 2.1.1 OPC Server Configuration To improve the system's openness, the "LabVIEW + OPC" design method was chosen. LabVIEW is used as the host computer monitoring software, and advanced network communication technology—DataSocket technology—is employed to achieve field data sharing through the OPC server interface. The OPC server used here is developed by Matrikon. It acts as an intermediary bridge, enabling data communication between the monitoring software LabVIEW and the field intelligent components. A one-to-one correspondence between the OPC configuration items and the data acquisition points of the underlying devices is established. As shown in the figure below: [align=center] Figure 2 Configuration items of OPC server[/align] The item name Name is a user-defined data acquisition point corresponding to the site. The item path must conform to the syntax requirements of the OPC server and MODBUS protocol, that is, "[port].Device.0～4:". At the same time, it is set whether the item is reading data or writing data, as well as the data type, update time, etc. [5]. 2.1.2 There are many ways for LabVIEW to access OPC in real time. This paper uses the Tag Configuration Editor engine in the DSC module to establish a connection between LabVIEW and the OPC server. The DSC module uses Tag to connect OPC data items. Through the Tag Configuration Editor, the DSC Tag can be mapped to the OPC data item to generate a .scf file, which is equivalent to LabVIEW's real time database, as shown in Figure 3. [align=center] Figure 3 .scf file[/align] The Item under the Connect directory of Analog Tag Configuration is matched with the item name of the OPC server, and the Tag is described in detail, such as OPC server, range of engineering quantity, upper and lower limits of alarm, update dead zone, etc. [3]. At runtime, the Tag Engine will establish a connection with the OPC server according to the configuration of the .scf file. After the OPC server and the .scf file are configured, the data collected on site can be read and written through the Numeric Control and Numeric Indicator controls on the front panel of LabVIEW. The Numeric Control and Numeric Indicator controls are matched with the Tag of the .scf file through the HMI Wizard for Analog Control, and the Label of the control is automatically set to the item name corresponding to the OPC configuration. The successful application of the DSC module makes the switching between interfaces more user-friendly; and successfully solves the problems of slow data update speed and slow switching between interfaces, ensuring the real-time and reliability requirements of control. 2.1.3 Report Generation Data collected on-site can be output to an Excel spreadsheet in report form for storage and browsing. However, LabVIEW itself lacks a robust real-time database; it only records data and stores it in a historical database through .scf files generated by the DSC module. However, this recording is based on the deviation defined by the log deadband, not on time. Data is only recorded when changes exceed the deviation, leading to mismatches between data and time when generating reports. Given these reasons, programming is generally a better approach. The programming is as follows: First, write the values ​​of the tags to be recorded to a table (e.g., a Table control) at time intervals (e.g., 1 hour). Then, write the data from the Table to an Excel spreadsheet based on the required number of data entries (e.g., 24), and then clear the Table. This method only requires the user to define the report output cycle and the data output cycle. For example, if one data entry is required per hour and one report is generated per day, simply set the data output cycle to 1 hour and the number of data entries to 24. So far, this method has proven very effective in on-site control applications. Especially during the programming process, two sub-VIs in LabVIEW were called: Generate Unique Filename.vi (used to indicate the report path and time) and Array to HTML Table.vi (used to generate the report format), which made the compilation of the flowchart simpler and more concise, and increased the reusability of the software. [align=center] Figure 4 Data Storage and Report Generation[/align] 2.2 Real-time and Historical Curve Display Trend curves can vividly depict the distribution trend of field data over a period of time. Through trend charts, operators can see the changes in various quantities based on the changing trends of data from each field data collection point, and can also view data at any historical moment for field operators to make appropriate adjustments. When implementing real-time curves, Trend Tags.vi provided by the DSC module was called. The input of this sub-VI is the tag and time length, and the size of the data range displayed on the X-axis and Y-axis can be programmed. When implementing historical curves, Read Trend.vi provided by the DSC module was called. Through the Historical Trend control, field data collected at any historical moment can be viewed. By selecting different field collection points, the range of the X-axis and Y-axis also changes accordingly. It is worth noting that the historical curve only displays a trend chart when the data change exceeds the set deviation. 2.3 Alarm Display and Fault Handling Monitoring software generally provides an alarm system. The alarm system can be used to generate, display, and store alarm information, and send alarm information to any node on the network, or to monitor printers, disk files, alarm summary displays, alarm history windows, and multimedia alarm systems connected to the monitoring host. The alarms can be arbitrarily sorted by the time of occurrence, registered in the database, and displayed on the computer. This article uses the DSC module to provide the Alarm Event Display control to display relevant on-site alarms and various application alarms. It can be used to display on-site event alarm information, including the measurement point that generated the alarm, the time of the alarm, the priority of the alarm, and the cause of the alarm, etc. After an alarm is generated, this information needs to be confirmed. After confirmation, the alarm confirmation time and the confirmer will be displayed in the alarm information bar; unresponsive faults will continuously emit audible and visual alarms and be indicated by flashing red. 2.4 Human-computer interaction and user security permissions LabVIEW provides a rich set of front panel controls, such as data connections, buttons, tables, curves, and even special decorative controls. The Image Navigator of the DSC module also contains a variety of icons (Symbols) to meet various user requirements. At the same time, .Bmp and .JPEG format images can be pasted on the front panel, which can fully realize the flow screen design of the monitoring software and make the human-computer interface more user-friendly [6]. Furthermore, in order to ensure the needs of normal production monitoring and prevent production stoppage and large economic losses caused by misoperation, it is necessary to clarify the scope of responsibilities of operators and prevent operators from exceeding their authority. Therefore, by setting various users based on security levels, the operation permissions of operators can be controlled at the application level to prohibit unauthorized operations. The DSC module provides NI User Account Manager, which can edit users with different security levels. When running the DSC Run-Time System, Invoke Login Dialog.vi is called to register users. The controllable controls on the front panel provide security attribute settings to define certain users and their operation permissions. In this way, each control can only be operated by predefined users. Users need to register with the corresponding permissions before they can control the control. This monitoring software sets three user levels: (1) Engineer level: can modify various parameters of the system configuration and clear the contents of the log file. (2) Operator level: can modify some parameters and perform remote calibration. (3) General level: can only view the screen and data, and cannot make any modifications or perform remote operations. 3 Conclusion The actual operation of this monitoring software has proven that LabVIEW's graphical programming environment can enable users to design a flexible monitoring system with rich and diverse screen quality and presentation. Furthermore, the functions provided by the DSC (Data Recording Monitoring) module, such as the library, VIs, and real-time database, can shorten the time required for users to configure the system and enhance the system's functionality. This monitoring software has been successfully applied to the FQA project of a pharmaceutical company. It not only meets various needs of on-site monitoring, but also has many advantages such as vivid and realistic graphics, close to the scene, simple and safe operation, flexible and convenient report printing, and reliable security. It has won high praise from users and once again verified the feasibility of LabVIEW-based monitoring software in process control. References: [1] Yang Leping, Li Haitao, et al. LabVIEW Programming and Application [M]. Beijing: Electronic Industry Press, 2002, 2 [2] LabVIEW Datalogging and Supervisory Control Module Developer Manual, April 2003 Edition, Part Number 321294F-01 [3] LabVIEW Datalogging and Supervisory Control Module Run-Time System Release Notes, March 2004, 3229560-01 [4] Yuan Chuming, et al. Research and Development of Real-Time Multi-Task Industrial Monitoring Configuration Software [J] Mechanical and Electronic, 2004, 2: 43-47 [5] Qiao Yi, Yuan Aijin, Tang Mingxin, Luan Meiyan. Implementation of Data Communication Based on LabVIEW and OPC [J] Control Engineering, 2005, 3: 153-155 [6] National Instruments China Branch. LabVIEW for Distributed Measurement and Control Systems [J] Instrumentation Technology, 2003, 3: 39-40