Information collection, verification and monitoring method for substation equipment operation software

Abstract

The invention relates to the technical field of power system automation, and in particular to a method for collecting, verifying and monitoring information of substation equipment running software. The method adopts a CS framework structure, deploys a collection service agent program on a collection service end of each device in a plant station, and deploys a monitoring client in zone II or IV in the plant station. The method comprises the following steps: S1: after receiving a "collection" command issued by a monitoring client, the collection service end obtains, parses and records mapping information of all running processes of each device in the plant station, generates a process tree and sends it to the monitoring client; S2: the monitoring client receives the running process information, generates a verification entry configuration of the device, and sends the verification configuration file to the collection service end; S3: equipment software verification library collection; S4: verification version library generation; S5: file version library dynamic monitoring; S6: version library comparison. The method can monitor the running status of the equipment software in real time and ensure stable and reliable operation of the equipment.

Description

Technical Field

[0001] The present invention relates to the technical field of power system automation, and in particular to a method for collecting, verifying and monitoring information of substation equipment operating software. Background Art

[0002] In recent years, with the rapid development of technology, the operation equipment and services of substations, especially new energy power plants, have become more and more complicated, involving a huge number of operating software and various files. When the software and key files are maliciously tampered with or misconfigured, the operation of the equipment software will be inconsistent with the expected state, posing a threat to the normal operation of the plant business, and even affecting the safe operation of the entire power. Therefore, the information collection of the operation status of the equipment software is crucial. However, the existing equipment software information collection mainly relies on the equipment software version number and verification code provided by the equipment manufacturer, and cannot verify the consistency of the software version of the on-site running equipment with the provided software. In addition, there is a lack of verification of the operating environment and key configuration files of the software in the equipment, and there is a lack of reliable collection and monitoring means for the operating environment, executable files, and key configuration files of the equipment software.

[0003] The Chinese invention patent application with publication number CN106775808A discloses a C / S architecture software automatic update and upgrade method based on a remote verification algorithm, wherein the client of each user collects the software version to be updated, verification value information and corresponding update policy information, and reports them to the server; the server summarizes the software version, verification value information and corresponding update policy information reported by the client of each user to form a software automatic update policy management file; when the new version of the application software is submitted to the version library of the server, the server issues an update notice according to the automatic update policy management file of each user; the client uses encoding and decoding technology and digital signature technology to form a verification value of the current version of the application software and sends it to the server; the server compares the verification value of the new version of the application software with the verification value of the current software version of the client; the server sends the software file version inconsistent with the client in the new version of the application software to the client through comparison; the client replaces the installation and operation file of the received file version with the file of the current version to complete the upgrade; the above-mentioned public scheme can unify the client software to be updated to the latest software version, thereby avoiding the "fragmentation" of the software version. The present invention aims to provide a method for collecting, verifying and monitoring the information of the equipment running software which is different from the above-mentioned disclosed scheme, so as to monitor the running status of the equipment software in real time, thereby ensuring the normal and safe operation of the plant and station business. Summary of the invention

[0004] Technical purpose: In order to overcome the deficiencies in the prior art, the present invention provides a method for collecting, verifying and monitoring information of substation equipment operating software.

[0005] Technical solution: To achieve the above purpose, the information collection, verification and monitoring method of the substation equipment operation software disclosed in the present invention adopts a CS framework structure, and the collection service agent is deployed on the collection service end of each device in the plant and station, and the monitoring client is deployed in the II or IV area of ​​the plant and station, including the following steps:

[0006] S1: After receiving the "collection" command sent by the monitoring client, the collection server obtains, parses and records the mapping information of all running processes of each device in the plant station, generates a process tree and sends it to the monitoring client;

[0007] S2: The monitoring client receives the running process information, generates the verification entry configuration of the device, and sends the verification configuration file to the collection server;

[0008] S3: Equipment software verification library collection: The collection server saves the configuration file locally, parses the configuration file, obtains the device name, model, manufacturer, software version, security zone, verification key process list, and static file-directory list; carries out process verification library collection and static file-directory list collection, and transmits the verification results to the monitoring client;

[0009] S4: Verify version library generation: The monitoring client receives the verification results and displays them. The operation and maintenance personnel adjust the file type, level and whether to monitor the file according to business needs, generate the version library file and save it to the local version library, and send it to the collection server at the same time;

[0010] S5: Dynamic monitoring of file version library: By running dynamic monitoring of program files and static monitoring of files, the checksums of all files are calculated and the current monitoring results are saved;

[0011] S6: Version library comparison: When the monitoring client receives an emergency or important alarm log, it can actively obtain the current monitoring results of the device, compare the version with the local version library, evaluate the reliability of the device operation, and determine the on-site running version.

[0012] Furthermore, the step S1 includes the following steps:

[0013] A1: After receiving the "collection" command from the monitoring client, the collection service agent program on the collection server searches the virtual file system of the device and obtains the mapping information of all running processes of the device;

[0014] A2: Parse the mapping information and record the name, process ID, parent process ID, process group ID, running status, file name, and command parameters of each process;

[0015] A3: Create a parent-child and sister relationship diagram of each process through the process ID and parent process ID of each process to form a process tree, and send it to the monitoring client for display.

[0016] Furthermore, the step S2 comprises the following steps:

[0017] B1: The monitoring client selects the required important processes according to the dependency relationship of the process tree based on the different services running on each device, adds static files and directories to ensure the operation of the device on the basis of the key process verification list, and generates the verification entry configuration of the device;

[0018] B2: Enter the device name, model, manufacturer, software version, verification entry, and security zone on the monitoring client, generate a verification configuration file for each device and send it to the collection server.

[0019] Furthermore, the process verification library collection in step S3 includes the following steps:

[0020] C1: Obtain the process currently running on the device and generate a process tree according to the method in step S1;

[0021] C2: Check whether each process in the key process list in the configuration file analysis exists in the process tree of step C1. If so, it means that the process is running normally; otherwise, it means that the process is not running normally. At this time, the collection server program generates an alarm log and uploads it to the monitoring client. The operation and maintenance personnel judge the equipment operation status and whether the configuration file verified by the monitoring client is accurate.

[0022] C3: Check that each process in the process tree of step C1 is included in the verification key process linked list, set the verification flag of the process to be verified to "TURE", check all its child processes through the process tree relationship table, and set the verification flag of the child process to be verified to "TURE";

[0023] C4: Check the check flag of each process in the process tree, parse the process with the check flag as "TRUE", analyze the memory mapping information, running directory and file stream of the process, and obtain the program files, system library files, third-party library files, configuration files and log files that the normal operation of the process depends on;

[0024] C5: Perform duplicate detection on the acquired program files, system library files, third-party library files, configuration files and log files, remove duplicate files, calculate the MD5 value of each file, and store the file path, file type, importance level, MD5 value and monitoring status of all files in the database.

[0025] Furthermore, the file path in step C5 is the full path name; the file types include program files, system library files, third-party library files, configuration files, log files and other files; the importance level is initially set according to the file type: program files are "1 urgent", system library files and third-party library files are "2 important", configuration files, log files and other files are "3 secondary"; program files to be run are marked as "TRUE"; log files that do not need to be monitored are marked as "FALSE".

[0026] Furthermore, the static file-directory linked list collection in step S3 includes the following steps:

[0027] D1: Check the attribute status of each item in the static file-directory list, including the file type and whether the file exists. If the file does not exist, the collection server program generates an alarm log and uploads it to the monitoring client. The operation and maintenance personnel determine whether the device configuration and device operation are normal and whether the configuration file verified by the monitoring client is accurate.

[0028] D2: For static files, the calculation module is directly called to calculate the verification code MD5 value of the file. For static directories, the verification code MD5 value of the static directory and its subdirectories is cyclically checked and calculated to complete the screening of static files in the directory. The file path, file type, importance level, MD5 value, whether it is running, and whether it is monitored of the verified static files are stored in the database.

[0029] Furthermore, the level of the file in step S4 is set as follows: the resident program file is an emergency <1> , library files and non-resident program files are important <2> , the configuration file can be set to important <2> or secondary <3> , other files are set to general <4> .

[0030] Furthermore, the dynamic monitoring of the running program file in step S5 includes the following steps:

[0031] E1: Obtain the process currently running on the device and generate a process tree according to the method in step S1;

[0032] E2: Run status judgment: Check the file level in the version library through the process tree in step E1 to see if it is urgent <1> Check whether the program file is running. If not, the collection service agent generates an alarm log and uploads it to the monitoring client;

[0033] E3: Program file operation analysis: The normally running program files are analyzed to obtain the dependent program files, system library files, third-party library files, configuration files and log files, and the file's MD5 value is calculated and compared with the version library file name and the checksum. If there is any discrepancy between the file name and the checksum to be monitored in the version library, the collection service agent generates an alarm log and uploads it to the monitoring client;

[0034] The static monitoring of files in step S5 includes the following steps:

[0035] F1: File status check: Periodically check the status of files to be monitored in the version library. If the file does not exist in the version library or the MD5 value of the existing file is inconsistent with the version library, an alarm log needs to be generated and uploaded to the monitoring client;

[0036] F2: File attribute monitoring: Real-time monitoring of version library files. When the content or attributes of a file change, the MD5 value of the file is calculated and compared with the version library, an alarm log is generated and uploaded to the monitoring client.

[0037] Furthermore, when the device software version is upgraded, it needs to run according to the steps S1 to S6. The same device only needs to collect the version of any one of the devices and generate a version library, and the other devices in the same device only need to complete the downloading and version monitoring of the version library.

[0038] The beneficial effects of the present invention are:

[0039] Wide monitoring scope: This method can monitor executable files, system dynamic libraries, third-party dependent libraries, configuration files / libraries, script files, etc. in the device; High monitoring accuracy: This method obtains the list of running processes in the device in a dynamic way, and parses the kernel information of the process when it is running. The obtained information cannot be modified externally, and the information is more accurate; Comprehensive monitoring content: It can monitor the running status of programs in the device in real time, generate alarms for abnormal exits of key programs, and send alarms to the client software when abnormal changes occur according to the level classification of entries in the version library. At the same time, the client software provides remote control services, including configuration viewing and modification, collection agent parameter setting, collection agent remote upgrade, etc. This method can monitor the running status of the equipment software in real time, thereby ensuring the normal and safe operation of plant and station services. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 It is a flow chart of the overall method in the present invention;

[0041] Figure 2 A flow chart of a method for generating a process tree in the present invention;

[0042] Figure 3 It is a schematic diagram of the process tree in the present invention;

[0043] Figure 4 This is a flowchart for verifying the version library generated in the present invention. DETAILED DESCRIPTION

[0044] The following combination Figure 1 — Figure 4 The principles and features of the present invention are described, and the examples given are only used to explain the present invention, rather than to limit the scope of the present invention.

[0045] Information collection, verification and monitoring methods for substation equipment operation software, such as Figure 1 As shown, the CS framework structure of distributed collection and centralized monitoring is adopted. The collection service agent is deployed on the collection service end of each device in the plant station, and the monitoring client is deployed in the II or IV area of ​​the plant station, which is responsible for the collection and aggregation, remote control, and alarm monitoring of all equipment software information in the entire plant station. Specifically, the collection service agent is a tcp server with a port number of 1915, and the plant station equipment software version monitoring software is a tcp client.

[0046] The method comprises the following steps:

[0047] S1: After receiving the "collection" command sent by the monitoring client, the collection service agent program on the collection server obtains, parses and records the mapping information of all running processes of each device in the plant station, generates a process tree and sends it to the monitoring client.

[0048] like Figure 2 — Figure 4 As shown, specifically, step S1 includes the following steps:

[0049] A1: After receiving the "collection" command from the monitoring client, the collection service agent program on the collection server searches the virtual file system of the device and obtains the mapping information of all running processes of the device.

[0050] A2: Parse the mapping information and record the name, process ID, parent process ID, process group ID, running status, file name, and command parameters of each process.

[0051] A3: Create a parent-child and sister relationship diagram of each process through the process ID and parent process ID of each process to form a process tree, and send it to the monitoring client for display.

[0052] S2: The monitoring client receives the running process information, generates the verification entry configuration of the device, and sends the verification configuration file to the collection server.

[0053] Specifically, step S2 includes the following steps:

[0054] B1: The monitoring client receives the process running information sent by each device, and selects the required important processes according to the dependency relationship of the process tree according to the different services running on each device. Specifically, after selecting the parent process, its child processes will be automatically verified without repeated selection. On the basis of verifying the key process linked list, the static files and directories that the normal operation of the device services depends on are added, such as configuration files, dynamic libraries, script files, etc., to generate the verification entry configuration of the device;

[0055] B2: Input the device name, model, manufacturer, software version, verification entry, and security zone on the monitoring client, generate a verification configuration file for each device, and send it to the collection service agent on the collection server.

[0056] S3: Equipment software verification library collection: After receiving the verification configuration file, the collection service agent on the collection server side saves the configuration file locally, that is, in the installation directory devinfo.json of the collection service agent, parses the configuration file, obtains the device name, model, manufacturer, software version, security zone, verification key process list, static file-directory list; carries out process verification library collection and static file-directory list collection, and transmits the verification results to the monitoring client.

[0057] Specifically, the process verification library collection in step S3 includes the following steps:

[0058] C1: Obtain the currently running process of the device and generate a process tree according to the method in step S1;

[0059] C2: Check the key process chain: Check whether each process in the key process chain list in "Configuration File Parsing" exists in the process tree of step C1. If it exists, it means that the process is running normally; otherwise, it means that the process is not running normally. At this time, the acquisition server program generates " <1> 2011-12-12 20:12:23.999 Monitoring server 1 key process WAJC is not running alarm" alarm log is uploaded to the monitoring client, and the operation and maintenance personnel determine whether the equipment operation status is normal and whether the configuration file verified by the monitoring client is accurate;

[0060] C3: Mark the key process in the process tree: Check that each process in the process tree of step C1 is included in the key process verification list, set the verification flag of the process to be verified to "TURE", check all its child processes through the process tree relationship table, and set the verification flag of the child process to be verified to "TURE" until the verification flags of all child processes are completely modified;

[0061] C4: Parse the memory mapping information of the running process: Check the check flag of each process in the process tree, parse the process with the check flag as "TRUE", analyze the memory mapping information, running directory and file stream of the running process, and obtain the program files, system library files, third-party library files, configuration files and log files that the normal operation of the process depends on;

[0062] C5: Checksum calculation and storage: The obtained program files, system library files, third-party library files, configuration files and log files are processed for duplicates, duplicate files are removed, and the calculation module is called to calculate the checksum MD5 value of each file. The file path, file type, importance level, MD5 value and whether it is monitored of all files are stored in the database.

[0063] The file path in step C5 is the full path name; the file types include program files, system library files, third-party library files, configuration files, log files and other files; the importance level is initially set according to the file type: program files are "1 urgent", system library files and third-party library files are "2 important", configuration files, log files and other files are "3 secondary"; the program files to be run are marked as "TRUE"; the log files that do not need to be monitored are marked as "FALSE", the log files are intermediate files of the device operation, the file content is constantly changing and has no monitoring significance, other types of dynamic library files, configuration files, program files, etc. do not change, according to actual needs, when monitoring is required, they are marked as "TRUE".

[0064] The static file-directory linked list collection in step S3 includes the following steps:

[0065] D1: Check the attribute status of each item in the static file-directory list. The attribute status includes the file type and whether the file exists. If the file does not exist, the collection service agent on the collection server generates a " <2> 2011-12-12 18:12:23.094 Monitoring server 1 static file / home / config.ini does not exist alarm" alarm log is generated and uploaded to the monitoring client. The operation and maintenance personnel determine whether the device configuration and operation are normal and whether the configuration file verified by the monitoring client is accurate;

[0066] D2: For static files, the calculation module is directly called to calculate the verification code MD5 value of the file. For static directories, the verification code MD5 value of the static directory and its subdirectories is cyclically checked and calculated, and the static files in the directory are screened according to the directory, extension name, and attributes of the file, and files that do not need to be verified are filtered out. The file path, file type, importance level, MD5 value, whether it is running, and whether it is monitored of the static files that have completed the verification are stored in the database.

[0067] S4: Verify version library generation: The monitoring client receives the verification results and displays them. The operation and maintenance personnel adjust the file type, level and whether to monitor according to business needs. After the adjustment is confirmed, the version library file is generated and saved to the local version library, and sent to the collection server at the same time.

[0068] The level of the file in step S4 is set as follows: the resident program file is emergency <1> , library files and non-resident program files are important <2> The configuration file can be set to important as needed. <2> or secondary <3> , other files are set to general <4> , cancel monitoring for files that do not need to be monitored, such as operation log files, historical library files, and temporary cache files.

[0069] S5: Dynamic monitoring of file version library: By running dynamic monitoring of program files and static monitoring of files, and calculating and obtaining the verification codes of all files, the current monitoring results are saved.

[0070] Specifically, the dynamic monitoring of the running program file in S5 includes the following steps:

[0071] E1: Obtain the currently running process of the device and generate a process tree according to the method in step S1;

[0072] E2: Run status judgment: Check the file level in the version library through the process tree in E1 to see if it is urgent <1> Is the program file running? If not, the collection service agent generates a " <1> 2011-12-12 20:12:23.999 Monitoring server 1 Program file / home / wajk file not running alarm" alarm log and upload to the monitoring client;

[0073] E3: Program file operation analysis: The program files that are running normally are analyzed to obtain the dependent program files, system library files, third-party library files, configuration files and log files, and the calculation module is called to calculate the MD5 value of the file's checksum, which is compared with the file name and checksum in the version library. If there is any discrepancy between the file name and the checksum to be monitored in the version library, an alarm log is generated and uploaded to the monitoring client. Specifically, if a new file appears, the collection service agent generates a " <2> 2011-12-12 20:12:23.999 Monitoring server 1 unknown file / home / libce.so new alarm" alarm log is uploaded to the monitoring client; if the verification code changes, the collection service agent generates " <2> 2011-12-12 20:12:23.999 "Monitoring server 1 library file / home / libdf.so modification alarm" alarm log is generated and uploaded to the monitoring client. The alarm level and file type are filled in according to the version library settings. Files that are set not to be monitored in the version library are not monitored by alarm.

[0074] The static file monitoring in step S5 includes the following steps:

[0075] F1: File status check: Periodically check the status of files to be monitored in the version library. If the version library file does not exist or the MD5 value of the existing file is inconsistent with the version library, an alarm log needs to be generated and uploaded to the monitoring client; specifically, if the version library file does not exist, the collection service agent generates a " <2> 2011-12-12 20:12:23.098 "Monitoring server 1 library file / home / libse.so missing alarm" alarm log is uploaded to the monitoring client. The existing file calls the calculation module to calculate the MD5 value of the file and compares it with the version library. If it is inconsistent, the collection service agent generates a " <2> 2011-12-12 20:12:23.999 Monitoring server 1 library file / home / libdf.so modification alarm" alarm log is uploaded to the monitoring client, and the alarm level and file type are filled in according to the version library settings;

[0076] F2: File attribute monitoring: Real-time monitoring of version library files. When the content or attributes of a file change, the MD5 value of the file is calculated and compared with the version library, an alarm log is generated and uploaded to the monitoring client. Specifically, the existing version library files are monitored in real time through epoll+inotify+callback. When the content or attributes of a file change, the calculation module is used to calculate the MD5 value of the file's checksum and compare it with the version library. If the checksum is inconsistent, a " <2> 2011-12-12 20:12:23.999 Monitoring server 1 library file / home / libdf.so modification alarm" alarm log is uploaded to the monitoring client, otherwise it will generate " <4> 2011-12-12 20:12:23.999 "Monitoring server 1 library file / home / libdf.so permission change alarm" alarm log is generated and uploaded to the monitoring client.

[0077] By running dynamic monitoring of program files and static monitoring of files, the program files, system library files, third-party library files, configuration files and other files that the device depends on for operation are obtained, and the verification codes of all files are calculated.

[0078] S6: Version library comparison: When the monitoring client receives an emergency or important alarm log, it can actively obtain the current monitoring results of the device as needed, compare the version with the local version library, and evaluate the reliability of the device operation and determine the on-site running version based on the comparison results.

[0079] After the device software version is upgraded, S1 to S6 need to be executed to restart the process collection, configuration generation, version verification, version library generation and download, and version monitoring. For the same device, only the version of any one device needs to be collected and the version library needs to be generated. Other devices in the same device only need to complete the version library download and version monitoring.

[0080] In this method, the acquisition service agent program dynamically obtains the process relationship tree of the running software in the device according to the command of the monitoring client, finds the main process and key file list of the device, analyzes the process running information, calculates the checksum of the file, and generates the version library of the device software running. At the same time, the running status of the device software can be monitored in real time. When the software and key files in the device change, according to the level classification of the version library entries, an alarm prompt is generated to the client software to ensure stable and reliable operation of the device.

[0081] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. The information collection, verification and monitoring method of the substation equipment operation software adopts the CS framework structure, the collection service agent is deployed on the collection service end of each equipment in the plant and station, and the monitoring client is deployed in the II or IV area of ​​the plant and station, which is characterized by: The following steps are involved: S1: After receiving the "collection" command sent by the monitoring client, the collection server obtains, parses and records the mapping information of all running processes of each device in the plant station, generates a process tree and sends it to the monitoring client; S2: The monitoring client receives the running process information, generates the verification entry configuration of the device, and sends the verification configuration file to the collection server; The step S2 comprises the following steps: B1: The monitoring client selects the required process according to the dependency relationship of the process tree based on the different services running on each device, adds static files and directories to ensure the operation of the device on the basis of the key process chain list, and generates the device verification entry configuration; B2: Enter the device name, model, manufacturer, software version, verification entry, and security zone on the monitoring client, generate a verification configuration file for each device, and send it to the collection server; S3: Equipment software verification library collection: The collection server saves the configuration file locally, parses the configuration file, obtains the device name, model, manufacturer, software version, security zone, verification key process list, and static file-directory list; carries out process verification library collection and static file-directory list collection, and transmits the verification results to the monitoring client; The static file-directory linked list acquisition in step S3 includes the following steps: D1: Check the attribute status of each item in the static file-directory list, including the file type and whether the file exists. If the file does not exist, the collection server program generates an alarm log and uploads it to the monitoring client. The operation and maintenance personnel determine whether the device configuration and device operation are normal and whether the configuration file verified by the monitoring client is accurate. D2: For static files, the calculation module is directly called to calculate the MD5 value of the file's verification code. For static directories, the verification code MD5 value of the static directory and its subdirectories is cyclically checked and calculated to complete the screening of static files in the directory. The file path, file type, importance level, MD5 value, whether it is running, and whether it is monitored of the verified static files are stored in the database; S4: Verify version library generation: The monitoring client receives the verification results and displays them. The operation and maintenance personnel adjust the file type, level and whether to monitor the file according to business needs, generate the version library file and save it to the local version library, and send it to the collection server at the same time; S5: Dynamic monitoring of file version library: By running dynamic monitoring of program files and static monitoring of files, the checksums of all files are calculated and the current monitoring results are saved; S6: Version library comparison: When the monitoring client receives an emergency or important alarm log, it can actively obtain the current monitoring results of the device, compare the version with the local version library, evaluate the reliability of the device operation, and determine the on-site running version.

2. The information collection, verification and monitoring method of substation equipment operation software according to claim 1 is characterized in that: The step S1 comprises the following steps: A1: After receiving the "collection" command from the monitoring client, the collection service agent program on the collection server searches the virtual file system of the device and obtains the mapping information of all running processes of the device; A2: Parse the mapping information and record the name, process ID, parent process ID, process group ID, running status, file name, and command parameters of each process; A3: Create a parent-child and sister relationship diagram of each process through the process ID and parent process ID of each process to form a process tree, and send it to the monitoring client for display.

3. The information collection, verification and monitoring method of substation equipment operation software according to claim 2 is characterized in that: The process verification library acquisition in step S3 includes the following steps: C1: Obtain the process currently running on the device and generate a process tree according to the method in step S1; C2: Check whether each process in the key process list in the configuration file analysis exists in the process tree of step C1. If so, it means that the process is running normally; otherwise, it means that the process is not running normally. At this time, the collection server program generates an alarm log and uploads it to the monitoring client. The operation and maintenance personnel judge the equipment operation status and whether the configuration file verified by the monitoring client is accurate. C3: Check that each process in the process tree of step C1 is included in the verification key process linked list, set the verification flag of the process to be verified to "TURE", check all its child processes through the process tree relationship table, and set the verification flag of the child process to be verified to "TURE"; C4: Check the check flag of each process in the process tree, parse the processes with the check flag "TRUE", analyze the memory mapping information, running directory and file stream of the process, and obtain the program files, system library files, third-party library files, configuration files and log files that the normal operation of the process depends on; C5: Perform duplicate detection on the acquired program files, system library files, third-party library files, configuration files and log files, remove duplicate files, calculate the MD5 value of each file, and store the file path, file type, importance level, MD5 value and monitoring status of all files in the database.

4. The information collection, verification and monitoring method of substation equipment operation software according to claim 3 is characterized in that: The file path in step C5 is the full path name; the file types include program files, system library files, third-party library files, configuration files, log files and other files; the importance level is initially set according to the file type: program files are "1 urgent", system library files and third-party library files are "2 important", configuration files, log files and other files are "3 secondary"; program files to be run are marked as "TRUE"; log files that do not need to be monitored are marked as "FALSE".

5. The method for collecting, verifying and monitoring information of substation equipment operation software according to claim 4, characterized in that: The file level in step S4 is set as follows: the resident program file is an emergency <1> , library files and non-resident program files are important <2> , the configuration file can be set to important <2> or secondary <3> , other files are set to general <4> .

6. The method for collecting, verifying and monitoring information of substation equipment operation software according to claim 5, characterized in that: The dynamic monitoring of the running program file in step S5 comprises the following steps: E1: Obtain the process currently running on the device and generate a process tree according to the method in step S1; E2: Run status judgment: Check the file level in the version library through the process tree in step E1 to see if it is urgent <1> Whether the program file is running, if not, the collection service agent generates an alarm log and uploads it to the monitoring client; E3: Program file operation analysis: The normally running program files are analyzed to obtain the dependent program files, system library files, third-party library files, configuration files and log files, and the file's MD5 value is calculated and compared with the version library file name and the checksum. If there is any discrepancy between the file name and the checksum to be monitored in the version library, the collection service agent generates an alarm log and uploads it to the monitoring client; The static monitoring of files in step S5 includes the following steps: F1: File status check: Periodically check the status of files to be monitored in the version library. If the file does not exist in the version library or the MD5 value of the existing file is inconsistent with the version library, an alarm log needs to be generated and uploaded to the monitoring client; F2: File attribute monitoring: Real-time monitoring of version library files. When the content or attributes of a file change, the MD5 value of the file is calculated and compared with the version library, an alarm log is generated and uploaded to the monitoring client.

7. The method for collecting, verifying and monitoring information of substation equipment operation software according to claim 6, characterized in that: When the device software version is upgraded, it needs to run according to the steps S1 to S6. The same device only needs to collect the version of any one of the devices and generate a version library. The other devices in the same device only need to complete the downloading and version monitoring of the version library.

Images