Abstract: This paper analyzes the current status of data utilization in the Hengshui power grid SCADA system, identifies the reasons for low data utilization, and proposes to convert the non-standard database of the SCADA system into an Oracle standard database and manage the data using a standard database language, thereby improving the data utilization rate. Keywords : Oracle SCADA, data utilization rate 0 Introduction With the continuous improvement of the automation level of the Hengshui power grid dispatch, the accuracy of telemetry and teleindication data is also constantly improving. A large amount of data from power grid operation not only serves as the basis for scientific dispatch but also plays an increasingly important role in assisting company decision-making. For example, when arranging power grid operation modes, dispatch personnel need a large amount of statistical information such as active power and voltage at each station every month; the planning department needs historical power grid operation data as the basis for planning; and the power consumption department needs telemetry information from the urban power grid as a reference for its work. In short, the demand for data from various departments of the enterprise is constantly increasing. 1 Current Status of Data Utilization in the Hengshui Power Grid Dispatch Automation System 1.1 Hengshui Power Grid Data Utilization Rate The data stored in the Hengshui power grid dispatch automation system falls into two categories: telemetry values ​​and computational data. The system stores not only 288 real-time values ​​for 5-minute intervals daily, but also daily statistical values ​​(such as maximum, minimum, and corresponding time, among 14 attributes). Currently, the system contains 685 calculations and 2430 telemetry measurements. There are 128 real-time data reports and 19 statistical data reports, with each report averaging 576 data points. Based on the above analysis, we calculated the current data utilization rate. (Total real-time data stored daily = 288 × (2430 + 685) = 897120 data points; total usable data = 576 × 128 = 73728 data points. Total statistical data stored daily = 14 × (2430 + 685) = 43610 data points; total usable data = 576 × 19 = 10944 data points.) From the table above, we can see that the utilization rate of the data stored in the Hengshui power grid dispatch automation system is only about 9%, and a large amount of power grid operation data cannot be directly accessed. 1.2 Data Access Flow of Hengshui Power Grid Dispatch Automation System [align=center][IMG=SCADA System Data Access Flow]/uploadpic/THESIS/2008/1/2008012516013480943Q.gif[/IMG] Figure 1 SCADA System Data Access Flow[/align] The system design adopted a non-standard database, limiting access to system data. Access to system data could only be achieved using the functions provided by the PGC2000 system, thus restricting data access. 2. Solutions The above analysis shows that the limitations of system functions and the lack of a standard database are the main reasons for low data utilization. Regarding the limitations of system functions, in a single SCADA system, database creation and management are done via files. Dispatchers only access screens, and system maintenance personnel perform data insertion and modification operations. Increasing the number of screens to improve data utilization would inevitably sacrifice system response time and stability, which is undesirable. The system does not use a standard database, which leads to cumbersome data utilization methods and unreasonable data access methods. The cumbersome data utilization methods prevent users from accessing the data they need within the expected time, and the unreasonable data access methods cause excessive host load, preventing effective response to user data requests. All of these factors limit user access to system data, resulting in low data availability. We decided to improve data utilization by converting the non-standard database to a standard database without modifying the existing software. To this end, we developed the following solution: a. Select a suitable network structure; b. Install Oracle database management software and establish the database table structure; c. Clarify the data storage format of the SCADA system and write a data conversion module; d. Use a standard database query language for data querying. 3 Implementation Steps 3.1 Network Structure Selection To reduce the burden on the real-time server, the existing two Compaq DS-10 minicomputers were used as historical servers, each with an Oracle database installed in a client/server architecture. The standard database was stored on the historical servers, and Oracle clients were installed on workstations. Users accessed the database from the workstations via the network. 3.2 Establishing the Table Structure In the Hengshui Power Grid SCADA system, data is stored on a daily basis, with one data file generated each day. A small amount of computation is performed on an annual basis, with one file generated each year. Statistics are compiled at midnight each day, and this file is updated to add records. Due to the large amount of data and to maintain consistency with existing practices, a data dictionary file containing station names, station numbers, point names, and point numbers is created when designing the Oracle database. Simultaneously, a historical data table file is created for the telemetry data of each year, and a statistical data table file is created for the statistical values ​​of the telemetry data of each year. a. Create a data dictionary file containing station name, station number, point name, and point number: CREATE TABLE DBDICTIONARY ( SERIAL int NOT NULL , STNNO int NOT NULL , PNTNO int NOT NULL , PNTTYPE char (1) NOT NULL , STNNAME varchar2 (40) NOT NULL , PNTNAME varchar2 (40) NOT NULL , DTCREATE date NULL , PRIMARY KEY ("SERIAL"), UNIQUE ("SERIAL") ) PARTITION BY RANGE (STNNO) (...) … b. Create an annual statistical table containing daily maximum (minimum) values, maximum (minimum) value times, average values, etc.: CREATE TABLE DBSTATISTICS2005 ( SERIAL int NOT NULL , DTDATE date NOT NULL , NUM_VALID int NOT NULL , NUM_NORMAL int NOT NULL , MAXIMUM real NOT NULL , DTMAXIMUM date NOT NULL , … ） PARTITION BY RANGE (DTDATE) (…) … c. Create an annual real-time value table for all 288 points of the day, including all telemetry points and calculation points: CREATE TABLE DBHISTORY2005 ( SERIAL int not null, DTDATE date not null, D1 real, D2 real,… ) PARTITION BY RANGE (DTDATE) (…) … 3.3 Writing the Data Conversion Module Because the manufacturer used a non-standard database for data storage, we were unsure of the data storage format. Therefore, we collaborated with the manufacturer to write a data conversion module. When designing the data conversion module, we considered the following issues: a. The data conversion module should not depend on the main scheduling automation program and should have good portability; b. Due to the use of a dual-machine redundant network structure, the data conversion module should have the function of flexibly selecting the data source and destination database. c. The data conversion module can run automatically or manually to ensure that the historical database can be modified promptly after the real-time database is modified. d. To meet the requirements of data query flexibility, the data conversion module should have the function of flexibly selecting the conversion time period. 4 Implementation Results 4.1 After repeated modifications, the main interface of the data conversion program is shown in the following figure: Source: Power Transmission and Distribution Equipment Network [align=center][IMG=Main Interface of Data Conversion Program]/uploadpic/THESIS/2008/1/2008012516060267409N.gif[/IMG] Figure 2 Main Interface of Data Conversion Program[/align] This data conversion module can be used to easily convert non-standard database files generated by the SCADA system into standard Oracle database files. 4.2 The data access process after conversion is shown in Figure 3. [align=center][IMG=Data Access Flowchart]/uploadpic/THESIS/2008/1/2008012516060687663M.gif[/IMG] Figure 3 Data Access Flowchart[/align] The advantages of this data access method are: a. It facilitates data querying using standard database query languages; b. It facilitates network load balancing; c. It improves the fault tolerance of the entire power grid dispatch automation system; d. It improves the security of data storage. 4.3 Application Example: To query the maximum value of PID "02A011" in 2005, the following statement can be used: `select max(maximum) from dbdictionary, dbstatistics2005 where dbdictionary.serial = dbstatistics2005.serial and dbdictionary.stnno = 02 and dbdictionary.pnttype = A and dbdictionary.pntno = 11` 5 Conclusion By converting power grid operation data to an Oracle standard database, data queries at any point can be performed using standard database query language. SCADA-collected data can be better shared by various departments within the enterprise, greatly improving data utilization.