Data processing method and device of feeder terminal, electronic equipment, computer readable storage medium and computer program product

Abstract

This application provides a data processing method, apparatus, electronic device, computer-readable storage medium, and computer program product for a feeder terminal. The method includes: parsing the device model file of the feeder terminal using a physical model to obtain a list of attributes, services, and events, and generating a user interface; loading an operation and maintenance template including a test command sequence and a set of expected test results through the user interface; sending the test command sequence to the feeder terminal to execute tests, recording test process information, comparing the actual test result set with the expected test result set, and generating a debugging record report based on the test process information; performing operation and maintenance operations on the feeder terminal through the user interface, and generating an operation and maintenance log based on the operation and maintenance operations and response results; and integrating the debugging record report and the operation and maintenance log to obtain a full lifecycle archive. This application enables automated debugging and standardized operation and maintenance of feeder terminals from multiple manufacturers, and improves operation and maintenance efficiency and intelligent management.

Description

Technical Field

[0001] This application relates to power system automation technology, and more particularly to a data processing method, apparatus, electronic device, computer-readable storage medium, and computer program product for a feeder terminal. Background Technology

[0002] The power distribution network is an important component of the power system, and the feeder terminal unit (FTU), as a key device in distribution automation, directly affects the reliability of power supply. Effective data processing and status monitoring are necessary during the installation, commissioning, operation, and maintenance of feeder terminals.

[0003] In related technologies, the operation and maintenance of feeder terminals from different manufacturers usually rely on incompatible dedicated software. The debugging and testing process is mostly performed manually, and the generated operation and maintenance data is scattered and lacks systematic management. Therefore, how to efficiently and systematically complete the operation and maintenance of feeder terminals and integrate and manage the data is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0004] This application provides a data processing method, apparatus, computer-readable storage medium, and computer program product for feeder terminals. Based on object models and maintenance templates, it enables automated debugging and standardized operation and maintenance of feeder terminals from multiple manufacturers, and constructs a full lifecycle archive for the equipment, thereby improving operation and maintenance efficiency and intelligent management level.

[0005] The technical solution of this application embodiment is implemented as follows: This application provides a data processing method for a feeder terminal, the method comprising: The device model file of the feeder terminal is parsed using a preset object model to obtain the attribute list, service list and event list of the feeder terminal, and a user operation interface is generated based on the attribute list, service list and event list. The user interface loads a preset operation and maintenance template, which includes a test instruction sequence and a set of expected test results corresponding to the test instruction sequence. The test instruction sequence is sent to the feeder terminal to execute the test, and the test process information is recorded. The actual test result set obtained after the test is executed is compared with the expected test result set, and a debugging record report is generated based on the comparison result and the test process information. The user interface is used to perform maintenance operations on the feeder terminal, and maintenance logs are generated based on the maintenance operations and their response results. By integrating the debugging record report and the operation and maintenance log, a full lifecycle file of the feeder terminal is obtained.

[0006] This application provides a data processing device for a feeder terminal, including: The user interface generation module is used to parse the device model file of the feeder terminal using a preset object model to obtain the attribute list, service list and event list of the feeder terminal, and generate a user interface based on the attribute list, service list and event list. The debugging record generation module is used to load a preset operation and maintenance template through the user operation interface. The preset operation and maintenance template includes a test instruction sequence and a set of expected test results corresponding to the test instruction sequence. The module sends the test instruction sequence to the feeder terminal to execute the test and records the test process information. It compares the actual test result set obtained after the test with the expected test result set and generates a debugging record report based on the comparison result and the test process information. The operation and maintenance log generation module is used to perform operation and maintenance operations on the feeder terminal through the user operation interface, and generate operation and maintenance logs based on the operation and maintenance operations and the response results of the operation and maintenance operations. The life record generation module is used to integrate the debugging record report and the operation and maintenance log to obtain the full life record of the feeder terminal.

[0007] In the above scheme, the operation interface generation module is further used to parse the state quantities and configuration quantities in the device model file using the preset object model, wherein the state quantities are used to characterize the current state of the feeder terminal, and the configuration quantities are used to characterize the operating parameters of the feeder terminal, and the state quantities and configuration quantities are integrated into the attribute list; using the preset object model, the module parses the services that can be called in the device model file and generates the service list including all the services; using the preset object model, the module parses the events that can be actively reported by the feeder terminal in the device model file and integrates all the events into the event list.

[0008] In the above scheme, the user interface generation module is further used to obtain a preset interface layout template, wherein the interface layout template includes a data monitoring area, a remote control area, and a real-time event sequence recording area; based on the attribute list, generate data display items in the data monitoring area of ​​the interface layout template; based on the service list, generate operation controls in the remote control area of ​​the interface layout template; and based on the event list, generate an event log display area in the real-time event sequence recording area of ​​the interface layout template to obtain the user interface, wherein the event log display area is used to present events in the event list.

[0009] In the above scheme, the debug record generation module is also used to obtain a test process information template; for each test instruction in the test instruction sequence, the following steps are performed: based on the wireless communication protocol, the current test instruction is encoded into a test instruction message; the test instruction message is encrypted using a preset session key, and the encrypted test instruction message is sent to the feeder terminal via wireless communication, and the sent test instruction message and the timestamp corresponding to the test instruction message are synchronously recorded in the test process information template; the response message corresponding to the current test instruction is received from the feeder terminal, and the response message is parsed to obtain the actual test result corresponding to the current test instruction and the response result corresponding to the current test instruction, and the response result and the timestamp corresponding to the response result are synchronously recorded in the test process information template to obtain the test process information.

[0010] In the above scheme, the debug record generation module is also used to integrate the actual test results corresponding to each test instruction to obtain the actual test result set; compare the actual test result set with the expected test result set to obtain the comparison result; and integrate the test process information and the comparison result to generate the debug record report.

[0011] In the above scheme, the operation and maintenance log generation module is further configured to: obtain the operation and maintenance operation instruction corresponding to the operation and maintenance operation; convert the operation and maintenance operation instruction into an operation and maintenance operation message based on a wireless communication protocol; encrypt the operation and maintenance operation message using a preset session key; and send the encrypted operation and maintenance operation message to the feeder terminal via wireless communication; receive the operation and maintenance response message returned by the feeder terminal; parse the operation and maintenance response message to obtain the response result of the operation and maintenance operation; and record the operation and maintenance operation and the response result of the operation and maintenance operation to obtain the operation and maintenance log.

[0012] In the above scheme, the life record generation module is also used to obtain the initial test report and identity identifier of the feeder terminal, and create a record file based on the identity identifier; store the initial performance data in the initial test report as baseline data in the record file; and store the debugging record report and the operation and maintenance log in the record file in chronological order to obtain the full life record.

[0013] In the above scheme, the data processing device of the feeder terminal further includes: a key generation module, used to send a first authentication request to the feeder terminal; receive a second authentication request returned by the feeder terminal and the response result of the first authentication request, wherein the second authentication request includes the identity identifier of the feeder terminal; when the response result of the first authentication request is correct and the identity identifier of the feeder terminal is valid, generate a preset session key, and use the preset session key to establish an encrypted wireless communication connection with the feeder terminal.

[0014] This application provides an electronic device, the electronic device comprising: Memory is used to store executable instructions or computer programs. The processor, when executing computer-executable instructions or computer programs stored in the memory, implements the data processing method for the feeder terminal provided in the embodiments of this application.

[0015] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions, which, when executed by a processor, implements the data processing method for the feeder terminal provided in this application.

[0016] This application provides a computer program product, including a computer program or computer executable instructions. When the computer program or computer executable instructions are executed by a processor, they implement the data processing method for the feeder terminal provided in this application.

[0017] The embodiments of this application have the following beneficial effects: By parsing the device model file of the feeder terminal using a pre-defined object model, a standardized user interface is generated. A pre-defined maintenance template containing test command sequences and expected test result sets is loaded, automatically sending commands to the feeder terminal to execute tests, comparing results, and generating debugging record reports. This achieves standardized operation and automated testing of the feeder terminal, improving the efficiency and standardization of maintenance work. Simultaneously, this application integrates the generated debugging record reports with maintenance logs generated from manual maintenance operations, ultimately obtaining a full lifecycle archive associated with a specific feeder terminal. This constructs a systematic data integration and management mechanism, providing a complete data foundation for subsequent data traceability and analysis, and improving data management capabilities. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the data processing system architecture of the feeder terminal provided in the embodiments of this application; Figure 2 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application; Figure 3 This is a first flowchart illustrating the data processing method for a feeder terminal provided in an embodiment of this application; Figure 4 This is a second flowchart illustrating the data processing method for a feeder terminal provided in an embodiment of this application; Figure 5 This is a schematic diagram of the third process of the data processing method for the feeder terminal provided in the embodiments of this application; Figure 6 This is a fourth flowchart illustrating the data processing method for a feeder terminal provided in an embodiment of this application; Figure 7 This is a fifth flowchart illustrating the data processing method for the feeder terminal provided in this application embodiment; Figure 8 This is a sixth flowchart illustrating the data processing method for a feeder terminal provided in this application embodiment; Figure 9 This is a seventh flowchart illustrating the data processing method for a feeder terminal provided in this application embodiment; Figure 10 This is a flowchart illustrating the data processing method for the feeder terminal provided in this application embodiment, in a field operation scenario where the handheld terminal hardware and the back-end management system work together.

[0019] It should be noted that the terms "first" and "second" mentioned above are only used to distinguish between different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0022] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0023] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0024] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0025] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0026] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0027] 1) Feeder Terminal Unit (FTU) is a key intelligent device installed on the feeder (i.e., power line) of the distribution network. It is used to monitor the operating status of the line in real time (such as voltage and current), execute remote control commands (such as switch opening and closing), and quickly locate and isolate faults. It is the basic unit for realizing distribution network automation.

[0028] 2) Communication protocol: A set of rules and conventions that two or more devices in a network should follow in order to understand each other and exchange data. The communication protocol specifies the data format, transmission order, error handling methods, etc., to ensure that information can be transmitted accurately and orderly between devices.

[0029] 3) Thing Model: A standardized description and abstraction of a physical entity in the digital world. In this application, it is specifically represented as a standardized data structure template. This template includes function names, function identifiers, data types (such as floating-point and Boolean), read / write permissions, and unit definitions, used to establish the mapping relationship between the physical functions of the feeder terminal and its digital spatial representation. The Thing Model defines what a physical entity "is," "what its states are" (attributes), "what it can do" (services), and "what will happen" (events), allowing upper-layer application software to interact with it in a unified way without needing to be concerned with the specific manufacturer and hardware differences of the equipment.

[0030] 4) Bluetooth unbalanced protocol, a master-slave communication rule based on Bluetooth communication. Under this protocol, communication is always initiated by the master device (such as a handheld maintenance terminal), which sends commands or requests data to the slave device (such as an FTU); the slave device only responds after receiving a request from the master device and never sends information on its own initiative.

[0031] 5) Encryption chip: A hardware integrated circuit specifically designed to perform security operations such as encryption, decryption, digital signature, and key management. It provides a physically secure environment to protect keys and algorithms. Compared to pure software implementation, it can greatly improve the security of device communication and data storage, preventing them from being cracked and tampered with.

[0032] 6) Full lifecycle archive: For a single device, a systematic and continuous collection and record of all key data and events throughout its entire lifecycle, from its manufacture, network access, commissioning, operation and maintenance, to its final scrapping. This is used to create a complete "birth to death" history for each device and is the core data foundation for condition assessment, fault tracing and asset management.

[0033] 7) Equipment model file, a description file provided by the feeder terminal manufacturer that follows a specific format (such as JSON, XML), containing all point table addresses, register definitions and private protocol format descriptions for that model of equipment.

[0034] 8) Operation and maintenance template, a structured data file or script file that can be edited by the user. It contains ordered test instruction steps, the judgment logic for each step to determine the test result, and configuration information such as timeout waiting time.

[0035] 9) Baseline data is a set of key performance indicators recorded when the feeder terminal passes the factory or network access test. The key performance indicators include, but are not limited to, inherent opening and closing time and sampling accuracy error value. This baseline data is used as a reference zero point for subsequent health status assessment of the feeder terminal.

[0036] 10) Human-computer interaction interface, which is used to provide human-computer interaction functions / display various data parsed from the feeder terminal.

[0037] For example, graphical user interfaces (GUIs) include augmented reality (AR) interfaces, virtual reality (VR) interfaces, voice user interfaces (VUIs), interactive projection interfaces (using projection technology to display information on a flat surface), eye-tracking interfaces (interfaces controlled by detecting the user's gaze), holographic interfaces (three-dimensional holograms formed by projecting images using holographic projection technology, allowing users to see stereoscopic images without wearing special glasses), multimodal interfaces (interfaces that combine multiple interaction methods, such as tactile, visual, and auditory interaction), and brain-machine interfaces (BMIs).

[0038] The power distribution network is an important component of the power system, and the feeder terminal unit (FTU), as a key device in distribution automation, directly affects the reliability of power supply. Effective data processing and status monitoring are necessary during the installation, commissioning, operation, and maintenance of feeder terminals.

[0039] In related technologies, the operation and maintenance of feeder terminals typically relies on dedicated maintenance software provided by equipment manufacturers. This approach has the following problems: First, feeder terminal equipment from different manufacturers typically comes with different and incompatible maintenance software and user interfaces. Maintenance personnel need to master multiple software tools simultaneously, which not only increases training costs and workload but also reduces on-site maintenance efficiency. Furthermore, the lack of a unified operating platform and standardized data models makes cross-device management extremely difficult when multiple devices need to be integrated or compared.

[0040] Secondly, traditional debugging and testing processes heavily rely on manual operation. Maintenance personnel need to manually execute a series of test instructions based on paper or electronic documents and verify the returned results item by item. This manual debugging method is not only inefficient and error-prone, but also lacks standardization, making it difficult to guarantee the consistency and reliability of testing work across different batches and by different personnel.

[0041] Furthermore, existing operation and maintenance methods typically lack a systematic data management mechanism. Various data generated during equipment commissioning, testing, and routine maintenance, such as commissioning records and operation logs, are often stored in a scattered manner, without forming a unified and continuous record. This makes it difficult to build a full lifecycle archive for equipment from commissioning to disposal, hindering long-term status tracking, fault analysis, and health status assessment, and limiting the level of intelligence in operation and maintenance management.

[0042] This application provides a data processing method, apparatus, device, computer-readable storage medium, and computer program product for feeder terminals. These technologies enable automated debugging and standardized operation and maintenance of feeder terminals from multiple manufacturers, improving operational efficiency and intelligent management. The following describes exemplary applications of the electronic devices provided in this application. These devices can be implemented as various types of terminals such as laptops, tablets, desktop computers, set-top boxes, smartphones, smart speakers, smartwatches, smart TVs, and vehicle terminals, or as servers. Exemplary applications when the device is implemented as a terminal will be described below.

[0043] See Figure 1 , Figure 1 This is a schematic diagram of the architecture of the data processing system 100 for the feeder terminal provided in this application embodiment. The terminal 400 is connected to the server 200 through the network 300, which can be a wide area network or a local area network, or a combination of the two.

[0044] This application provides a data processing method for a feeder terminal, aiming to solve the technical problems of low efficiency and management difficulties caused by the different equipment manufacturers, reliance on manual commissioning, and scattered maintenance data in power distribution network operation and maintenance. It can be widely applied to scenarios such as factory commissioning and acceptance of new equipment, fault diagnosis and scheduled maintenance of in-operation equipment, and functional verification after equipment firmware upgrades. The following will describe this method in conjunction with specific scenarios.

[0045] This application provides a data processing method for a feeder terminal, applicable to scenarios involving factory commissioning and acceptance testing of new equipment. In this scenario, the core task is to comprehensively verify the functionality of the new feeder terminal and establish its initial profile. The server pre-stores a standardized physical model and a set of preset maintenance templates for commissioning acceptance. The terminal carried by the on-site maintenance personnel first communicates with the server to download the latest physical model and the corresponding preset maintenance template for acceptance testing. Subsequently, the terminal establishes a wireless connection with the feeder terminal to be accepted, parses the device model file of the feeder terminal using the preset physical model, obtains its attribute list, service list, and event list, and generates a standardized user interface based on this. The operator loads the downloaded preset maintenance template for acceptance testing through this user interface. This maintenance template contains a complete sequence of test instructions (such as remote signaling / telemetry point-to-point testing, remote control opening and closing tests, etc.) and a precise set of expected test results. The terminal automatically sends a sequence of test commands to the feeder terminal to execute the tests and records detailed test process information. Then, it compares the actual test results with the expected test results item by item. Finally, based on the comparison results and test process information, it generates a formatted debug log report containing conclusions for all test items. The terminal then uploads this debug log report to the server. Upon receiving the report, the server creates and stores its initial full lifecycle archive for this unique feeder terminal, signifying that the feeder terminal has passed acceptance testing and is officially archived.

[0046] This application provides a data processing method for a feeder terminal, which can also be applied to scenarios of fault diagnosis and scheduled maintenance of in-operation equipment. In this scenario, when the power distribution master station system detects abnormal data from an online feeder terminal and issues a maintenance work order, maintenance personnel need to quickly locate and resolve the problem. The server pushes work order information and one or more targeted diagnostic preset maintenance templates to the maintenance personnel's terminal based on the alarm type. After arriving at the site, the maintenance personnel connect to the target feeder terminal and use the preset object model to parse the equipment model file to generate a user interface. The maintenance personnel first load the preset diagnostic maintenance template, execute a sequence of test instructions including reading fault information and testing key circuits, and automatically generate a preliminary debugging record report indicating possible fault points. Based on the diagnostic conclusions of this report, the maintenance personnel perform manual maintenance operations on the feeder terminal through the user interface (e.g., modifying setpoint parameters, resetting protection modules, etc.). The terminal records these maintenance operations and the feeder terminal's response results, and generates a maintenance log. After completing the repair operation, the maintenance personnel can run the preset maintenance template for diagnosis or a functional verification template again to generate a new debug log report showing that the test has passed. After the task is completed, the terminal packages and uploads all the data generated in this task—including the debug log report for fault diagnosis, the maintenance log recording the repair process, and the debug log report showing that the final verification has passed—to the server. After receiving this information, the server retrieves the existing full lifecycle archive of the feeder terminal and appends these new reports and logs in chronological order, thus completely recording the entire process from fault discovery to diagnosis, repair, and verification.

[0047] In some embodiments, the data processing method for the feeder terminal provided in this application can be implemented independently by the terminal 400. The terminal 400 parses the device model file of the feeder terminal using a preset object model to obtain the attribute list, service list, and event list of the feeder terminal, and generates a user interface based on the attribute list, service list, and event list. The terminal 400 loads a preset maintenance template through the user interface. The preset maintenance template includes a test instruction sequence and a set of expected test results corresponding to the test instruction sequence. The terminal 400 sends the test instruction sequence to the feeder terminal to execute the test, records the test process information, compares the actual test result set obtained after the test with the expected test result set, and generates a debugging record report based on the comparison result and the test process information. The terminal 400 performs maintenance operations on the feeder terminal through the user interface, and generates a maintenance log based on the maintenance operations and their response results. The terminal 400 integrates the debugging record report and the maintenance log to obtain a full lifecycle archive of the feeder terminal.

[0048] In some embodiments, the data processing method for the feeder terminal provided in this application can be implemented independently by the server 200. The server 200 parses the device model file of the feeder terminal using a preset object model to obtain the attribute list, service list, and event list of the feeder terminal, and generates a user interface based on the attribute list, service list, and event list. The server 200 loads a preset maintenance template through the user interface. The preset maintenance template includes a test instruction sequence and a set of expected test results corresponding to the test instruction sequence. The server 200 sends the test instruction sequence to the feeder terminal to execute the test, records the test process information, compares the actual test result set obtained after the test with the expected test result set, and generates a debugging record report based on the comparison result and the test process information. The server 200 performs maintenance operations on the feeder terminal through the user interface, and generates a maintenance log based on the maintenance operations and their response results. The server 200 integrates the debugging record report and the maintenance log to obtain a full lifecycle archive of the feeder terminal.

[0049] In some embodiments, the data processing method for the feeder terminal provided in this application can be implemented collaboratively by the terminal 400 and the server 200. The terminal 400 sends a request to the server 200 and downloads a preset object model and a preset maintenance template; the terminal 400 uses the preset object model to parse the device model file of the feeder terminal, obtaining the attribute list, service list, and event list of the feeder terminal, and generates a user interface based on the attribute list, service list, and event list; the terminal 400 loads the preset maintenance template through the user interface, the preset maintenance template including a test instruction sequence and a set of expected test results corresponding to the test instruction sequence; the terminal 400 sends the test instruction sequence to the feeder terminal to execute the test, and... The system records test process information, compares the actual test result set obtained after the test with the expected test result set, and generates a debug record report based on the comparison results and test process information. Terminal 400 performs operation and maintenance operations on the feeder terminal through the user interface, and generates operation and maintenance logs based on the operation and maintenance operations and their response results. Terminal 400 packages the debug record report and operation and maintenance logs and uploads them to server 200. Server 200 receives the debug record report and operation and maintenance logs uploaded by terminal 400, integrates the debug record report and operation and maintenance logs, and obtains the full life cycle archive of the feeder terminal.

[0050] In some embodiments, considering the possibility of poor network signal or no network connection in the field operation environment, this application embodiment also provides an offline working mode. Specifically, when the network connection between the terminal 400 and the server 200 is normal, the terminal 400 can pre-download and cache multiple commonly used object models and operation and maintenance templates from the server 200 to its local storage. When the field cannot connect to the server 200, the terminal 400 can directly load the locally cached object models and operation and maintenance templates to perform all offline operation and maintenance operations, and temporarily store the generated debugging record reports and operation and maintenance logs locally. When the network connection of the terminal 400 is restored, it can automatically or manually upload the locally temporarily stored operation and maintenance data to the server 200 through a preset communication protocol (such as the MQTT protocol), and the server 200 will complete the full lifecycle file update. This offline mode ensures that even in a network-free environment, the core operation and maintenance work on-site can be carried out without interruption, and guarantees the eventual consistency of data after the network is restored, significantly improving the field practicality and reliability of the solution.

[0051] In some embodiments, server 200 may be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. Terminals and servers can be connected directly or indirectly via wired or wireless communication, which is not limited in this embodiment.

[0052] See Figure 2 , Figure 2 This is a schematic diagram of the structure of the electronic device 500 provided in the embodiments of this application. The electronic device 500 can be implemented as follows: Figure 1 The terminal 400 in the middle, such as a handheld maintenance terminal or a laptop computer. Figure 2 The illustrated electronic device 500 includes at least one processor 510, a memory 550, at least one network interface 520, and a user interface 530. The various components in the electronic device 500 are coupled together via a bus system 540. It is understood that the bus system 540 is used to implement communication between these components. In addition to a data bus, the bus system 540 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 2 The general labeled all buses as Bus System 540.

[0053] The processor 510 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0054] User interface 530 includes one or more output devices 531 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. User interface 530 also includes one or more input devices 532, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0055] The memory 550 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 550 may optionally include one or more storage devices physically located away from the processor 510.

[0056] The memory 550 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 550 described in this application embodiment is intended to include any suitable type of memory.

[0057] In some embodiments, memory 550 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0058] Operating system 551 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks; The network communication module 552 is used to reach other electronic devices via one or more (wired or wireless) network interfaces 520, exemplary network interfaces 520 including: Bluetooth, WiFi, and Universal Serial Bus (USB), etc. Presentation module 553 is used to enable the presentation of information (e.g., user interface for operating peripheral devices and displaying content and information) via one or more output devices 531 (e.g., display screen, speaker, etc.) associated with user interface 530. The input processing module 554 is used to detect and translate one or more user inputs or interactions from one or more input devices 532.

[0059] In some embodiments, the apparatus provided in this application can be implemented in software. Figure 2 A data processing device 555 for a feeder terminal, stored in memory 550, is shown. This device can be software in the form of programs and plug-ins, and includes the following software modules: an operation interface generation module 5551, a debugging record generation module 5552, an operation and maintenance log generation module 5553, a life record generation module 5554, and a key generation module 5555. These modules are logically connected and can therefore be arbitrarily combined or further separated according to their implemented functions. The functions of each module will be described below.

[0060] In other embodiments, the apparatus provided in this application can be implemented in hardware. For example, the apparatus provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the data processing method of the feeder terminal provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0061] In some embodiments, the terminal or server can implement the data processing method of the feeder terminal provided in this application embodiment by running various computer-executable instructions or computer programs. For example, computer-executable instructions can be microprogram-level commands, machine instructions, or software instructions. Computer programs can be native programs or software modules in an operating system; they can be native applications (APPs), i.e., programs that need to be installed in the operating system to run; or they can be applets that can be embedded in any APP, i.e., programs that only need to be downloaded to a browser environment to run. In summary, the aforementioned computer-executable instructions can be any form of instruction, and the aforementioned computer programs can be any form of application, module, or plugin.

[0062] The following describes the data processing method for the feeder terminal provided in the embodiments of this application. As mentioned above, the electronic device implementing the data processing method for the feeder terminal in the embodiments of this application can be a terminal, a server, or a combination of both. Therefore, the executing entity of each step will not be described again below.

[0063] See Figure 3 , Figure 3 This is a first flowchart illustrating the image processing method provided in this application embodiment, which will be combined with... Figure 3 The steps shown are explained below. Figure 3 The main component of the process is electronic equipment.

[0064] In step 101, the device model file of the feeder terminal is parsed using a preset object model to obtain the attribute list, service list, and event list of the feeder terminal, and a user interface is generated based on the attribute list, service list, and event list.

[0065] Here, the object model refers to a pre-defined functional paradigm and data structure template, which is an abstract representation of physical devices such as feeder terminals in the digital world. Specifically, the object model logically divides all the capabilities of a physical device into three standard categories: attributes, services, and events. Attributes describe the current or configurable state parameters of the device, services define the complex operations that the device can perform remotely, and events summarize the notifications or alarms that the device actively reports under specific conditions. During the parsing process, the object model serves as a set of standardized mapping rules to accurately classify the flattened data points with mixed physical meanings in the device model file into the above three functional categories.

[0066] Here, the user interface refers to a graphical interactive interface that is automatically generated based on the parsed attribute list, service list, and event list. This graphical interactive interface is not a fixed, pre-coded interface, but rather dynamically maps the parsed data content and function categories to a preset interface layout.

[0067] In some embodiments, the device model file also includes definition information of the artificial intelligence model. Parsing the device model file of the feeder terminal using a preset object model further includes: parsing the definition information of the artificial intelligence model from the device model file according to the preset object model, and loading and generating an artificial intelligence model instance based on the definition information; the artificial intelligence model instance infers state variables based on the real-time operating data of the feeder terminal and generates diagnostic results or parameter tuning suggestions; when the diagnostic result indicates a fault, a fault alarm is automatically generated; when an execution instruction for parameter tuning suggestions is received, the parameter tuning suggestions are used as maintenance operations to automatically remotely control the feeder terminal.

[0068] In this embodiment, by extending the physical model with an artificial intelligence model, the depth and automation level of processing and utilizing operation and maintenance data are improved. Specifically, the artificial intelligence model autonomously analyzes and infers from the real-time operating data of the feeder terminal, achieving automatic fault diagnosis. Compared to relying on post-event data analysis by operation and maintenance personnel, this artificial intelligence model can detect potential abnormal patterns and generate fault alarms in real time, improving the timeliness of fault detection. Furthermore, the artificial intelligence model can generate optimized parameter configuration suggestions by analyzing the correlation between historical data and operating parameters, thereby supporting parameter self-tuning. This approach replaces the traditional method of adjusting parameters based on fixed thresholds or human experience, enabling the configuration of the feeder terminal to better match its actual operating conditions, thus reducing reliance on human experience and improving the accuracy of fault diagnosis and the scientific nature of operation and maintenance parameter adjustments.

[0069] In some embodiments, the preset object model can be obtained by: collecting and integrating industry standard specifications, communication protocol documents, and technical specifications from multiple feeder terminal manufacturers to form an original functional data set; performing semantic analysis and functional abstraction on the original functional data set, summarizing the data points used to characterize the device status or operating parameters into standardized attribute definitions, summarizing the specific operations that can be remotely invoked into standardized service definitions, and summarizing the notifications or alarms actively reported by the device into standardized event definitions; creating a unified data structure for each standardized attribute definition, standardized service definition, and standardized event definition, wherein the unified data structure includes at least the function name, data type identifier, and access permission description of each data item, thereby obtaining the preset object model.

[0070] For example, the DL / T634.5101-2002 communication specification was collected as an industry standard specification, the "State Grid Distribution Terminal Type I Communication Protocol" was collected as a communication protocol document, and technical specification documents of feeder terminal products from Company A, Company B and Company C were collected. All data points describing the functions of the feeder terminal in these documents were compiled to form a large set of original functional data with different formats.

[0071] Semantic analysis and functional abstraction were performed on this original functional data set. The analysis revealed that, despite the different names, multiple documents mentioned data representing the A-phase current value. For example, it was called "Ia" in Company A's manual, "Current_PhaseA" in Company B's manual, and "Information Body 101" in the communication protocol. After functional abstraction, these were unified into a standardized attribute definition named "A-phase current." Similarly, multiple documents described the operation of remotely disconnecting the switch, such as "remote tripping command" in the protocol and "remote tripping function" in Company C's manual. These operations were summarized into a standardized service definition named "remote tripping." Furthermore, the documents described how the equipment would report information when the current exceeded the set value, such as "overcurrent alarm" or "protection action event." This type of information was summarized into a standardized event definition named "overcurrent alarm event."

[0072] A unified data structure is created for each of the standardized definitions summarized above. For example, the data structure created for the standardized attribute definition "A-phase current" is {"Function Name": "A-phase current", "Data type identifier": "float", "Access permission description": "Read-only"}; the data structure created for the standardized service definition "Remote tripping" is {"Function Name": "Remote tripping", "Input parameters": [], "Output parameters": [{"Name": "Execution result", "Data type": "bool"}]}; the data structure created for the standardized event definition "Overcurrent alarm event" is {"Function Name": "Overcurrent alarm event", "Event level": "Warning", "Output parameters": [{"Name": "Overcurrent value", "Data type": "float"}]}. Combining all these standardized definitions with unified data structures yields the final, usable preset physical model.

[0073] In some embodiments, Figure 4 This is a second flowchart illustrating the data processing method for a feeder terminal provided in an embodiment of this application, as shown below. Figure 4 As shown, in step 101, "parse the device model file of the feeder terminal using the preset object model to obtain the attribute list, service list and event list of the feeder terminal", this can be achieved through the following steps 1011 to 1013.

[0074] In step 1011, using a preset object model, the state variables and configuration variables in the device model file are parsed out. The state variables are used to characterize the current state of the feeder terminal, and the configuration variables are used to characterize the operating parameters of the feeder terminal. The state variables and configuration variables are then integrated into an attribute list.

[0075] Here, the device model file refers to a data file provided by a specific feeder terminal manufacturer that describes all the digital functionalities of a particular model of device. The device model file lists the original definitions of all attributes, services, and events supported by the feeder terminal model in a structured format, such as JSON or XML, including manufacturer-defined identifiers, names, and data formats. During the parsing process, the device model file serves as the input source containing a complete list of the feeder terminal's original capabilities, while the preset object model serves as a set of standardized decoding rules used to identify and extract state variables, configuration variables, callable services, and proactively reported events that conform to the standard definitions from this manufacturer-specific list.

[0076] Continuing with the example above, suppose the device model file for a specific model of feeder terminal contains only two raw data point definitions from its manufacturer, Company B: a data point named Current_PhaseA and a data point named OC_Setting. In this case, the device model file is parsed using the preset object model obtained in the example above.

[0077] The parsing process first processes the data point Current_PhaseA. By querying the preset physical model, it is found that Current_PhaseA is defined as a specific implementation name of the standard attribute "A-phase current", and in the unified data structure of the standard attribute "A-phase current", the value of the "access permission description" field is set to "read-only". Based on this, "A-phase current" is determined to be a state variable, because it represents the objective measurement state of the device that cannot be directly modified externally.

[0078] Next, the parsing process handles the data point OC_Setting. Again, by querying the preset object model, it is found that OC_Setting corresponds to the standard attribute "Overcurrent Protection Setting," and in the unified data structure of "Overcurrent Protection Setting," the value of the "Access Permission Description" field is set to "Read / Write." Based on this, "Overcurrent Protection Setting" is determined to be a configuration variable, because it represents the internal operating parameters of the device that can be remotely configured to adjust its behavior.

[0079] Finally, by integrating the above analysis and classification results, we obtain the attribute list of the feeder terminal. The content of this attribute list is [{"Function Name": "Phase A Current", "Classification": "Status Quantity"}, {"Function Name": "Overcurrent Protection Setting", "Classification": "Configuration Quantity"}]. This attribute list transforms manufacturer-specific, unclassified data points into a standardized set of attributes that clearly distinguishes between status and configuration functions.

[0080] In some embodiments, the device model file is a file containing heterogeneous proprietary protocol data for a feeder terminal in a power system; by parsing the device model file of the feeder terminal using a preset object model, the heterogeneous proprietary protocol data can be standardized.

[0081] Here, heterogeneous proprietary protocol data refers to a set of data originating from feeder terminals of different manufacturers in the power system and generated in accordance with the communication protocols customized or extended by their respective manufacturers.

[0082] For example, the "Phase A current" reported by a feeder terminal from Manufacturer A might be located at address 0x4001, with a floating-point data type; while the same physical quantity reported by a feeder terminal from Manufacturer B might be located at address 0x500A, with a short integer data type, and needs to be multiplied by a coefficient of 0.01 to obtain the actual ampere value. These two sets of data together constitute heterogeneous proprietary protocol data.

[0083] In some embodiments, the state quantities may include telemetry state quantities and teleindication state quantities. The telemetry state quantities are continuously changing state quantities, such as phase A current, phase B current, phase C current, and battery voltage, while the teleindication state quantities are discrete switching quantities, such as switch status and fault indication.

[0084] In some embodiments, the configuration parameters can be overcurrent protection settings, reclosing counts, heartbeat reporting cycle, and IP address, etc.

[0085] In step 1012, using a preset object model, the services that can be called in the device model file are parsed out, and a service list including all services is generated.

[0086] Here, the services that can be invoked refer to a set of specific operations that are predefined by the feeder terminal and made available to the outside, and can be remotely triggered and executed. Unlike attributes used to describe the state of the equipment, each service represents a specific action or task with a clear start and end, such as remote time synchronization, equipment reset, or performing a circuit breaker opening and closing operation. A complete service definition usually includes the name of the service, the input parameters that must be provided when executing the service, and the result parameters returned after the service is executed. Therefore, parsing out these services is to generate corresponding control command entries, such as function buttons, on the user interface.

[0087] Continuing with the previous example, suppose a device model file for a feeder terminal from manufacturer C contains two manufacturer-defined operation commands in its data definition: one named `remote_trip_operation` and the other named `reboot_device`. In this case, the device model file is parsed using the preset object model obtained in the previous example.

[0088] The parsing process first processes the instruction `remote_trip_operation`. By querying and matching within the predefined object model, it is found that this instruction corresponds to the standardized service "remote tripping". Therefore, the complete definition of the standard service "remote tripping" is extracted from the object model. This definition includes the standard service name, the fact that no input parameters are required to execute the service, and that the service returns a boolean result after execution. Similarly, the instruction `reboot_device` is also parsed and matched to the standardized service "device reset", and its complete standardized definition is extracted.

[0089] All the parsed standardized services are integrated to generate a service list. This service list contains the complete definitions of the two standard services, "Remote Tripping" and "Equipment Reset." This list provides a direct basis for subsequently generating two standardized control buttons, "Remote Tripping" and "Equipment Reset," on the user interface, which are independent of specific equipment models.

[0090] In some embodiments, the services that can be invoked may include remote tripping, remote closing, device reset, and remote time synchronization.

[0091] In step 1013, using a preset object model, the events that can be actively reported by the feeder terminal in the device model file are parsed out, and all events are integrated into an event list.

[0092] Here, an actively reported event refers to a notification-type information that is triggered by the internal logic of the feeder terminal itself or its perception of the external environment, and is actively and asynchronously sent by the feeder terminal.

[0093] It should be noted that attributes are typically used to describe the continuous state of a device at any given time (such as the current voltage) and often require polling for reading, while events are instantaneous "snapshots" representing state changes or abnormal situations (such as "voltage over-limit alarm"), actively pushed by the device when the event occurs. Services are "commands" initiated to the feeder terminal (such as "remote tripping"), while events are "reports" issued by the feeder terminal.

[0094] It should be noted that since the device model files provided by different device manufacturers are essentially flat lists of data points with mixed functions and no inherent logical relationship, the function-oriented deep parsing method adopted in this application can force these raw and disordered data points to be mapped into three standardized categories with clear functional definitions: attributes, services, and events. This is equivalent to giving the originally chaotic data a unified and structured functional semantic layer, thereby solving the technical problems of poor compatibility and the need for separate protocol adaptation and function development for each device when directly processing heterogeneous device data, and providing a consistent interaction basis for all subsequent steps.

[0095] Continuing with the example above, suppose a device model file for a feeder terminal from Company A defines two information items that the device will actively report: one is Overcurrent_Alarm, triggered when the line current exceeds a preset threshold, and the other is Device_Heartbeat, which the device reports periodically. In this case, the preset object model obtained in the example above is used to parse the device model file.

[0096] The parsing process first processes the information item Overcurrent_Alarm. By querying and matching within the predefined object model, it is found that this information item corresponds to the standardized event "Overcurrent Alarm Event". Therefore, the complete definition of the standard event "Overcurrent Alarm Event" is extracted from the object model. This definition clarifies that this is a "warning" level event, and that a parameter called "Overcurrent Value" will be reported when the event occurs.

[0097] The item "Device_Heartbeat" was queried and matched in the object model. It was found that it did not belong to any "event" type definition, but was classified as a periodic "attribute" reporting behavior. Therefore, this item was not included when generating the event list.

[0098] All the parsed standardized events are integrated to obtain an event list. In this example, the event list only contains the "overcurrent alarm event" item. This list provides a basis for subsequently displaying alarm information from different manufacturers but of the same nature in a standardized format (such as a uniform event name) in the alarm log area of ​​the user interface.

[0099] In the embodiments of this application, a precise semantic classification of private protocol data points with mixed physical meanings in the feeder terminal equipment model file is performed based on a preset functional paradigm. Specifically, state variables representing the current state and configuration variables defining operating parameters are integrated into a unified attribute list, complex operations that can be remotely invoked are abstracted into a clear service list, and alarms or notifications actively reported by the device are summarized into a specific event list, thereby completing a function-oriented deep analysis. This analysis method eliminates the dependence of upper-layer application software on the specific communication protocols or point table addresses of the underlying devices by mapping private data points from different manufacturers to standardized attributes, services, and events. This allows the same set of user interface logic and the same set of operation and maintenance templates to adapt to devices from different manufacturers, because the upper-layer application operates on standardized "functions" (such as the "remote tripping" service) rather than manufacturer-specific "instructions" (such as sending 0xAB 0xCD messages), thereby greatly reducing the software adaptation development cost and the operational complexity of on-site operation and maintenance personnel.

[0100] In some embodiments, the events that are actively reported can be overcurrent alarms, switch change notifications, equipment self-test anomalies, protection action records, etc.

[0101] In some embodiments, proactively reported events may include an event name, an event level, and event details.

[0102] For example, proactively reported events include: Event name: Overcurrent alarm, Alarm level: Warning, Event details: The specific phase in which the overcurrent occurred (phase A / phase B / phase C) and the instantaneous current value that triggered the alarm.

[0103] For example, proactively reported events include: Event name: protection action, alarm level: severe, event details: the type of protection action (e.g., "instantaneous overcurrent protection" or "time-limit overcurrent protection") and detailed electrical parameters at the time of the fault.

[0104] In some embodiments, step 103 further includes the following steps: when a private data point that is not defined in the preset object model is detected in the device model file, a preset exception handling strategy is executed; the preset exception handling strategy includes at least one of the following: marking the private data point as an unknown attribute or unknown service and identifying it on the user interface; recording the private data point and its original definition information in a log file.

[0105] In the embodiments of this application, by setting an exception handling strategy, when parsing a device model file containing private data points that are not defined in the object model, the private data points can be identified and marked, while the parsing process of other standard data points is not interrupted. This ensures that the method of this application can still maintain stable program operation and good forward compatibility when processing device model files of feeder terminals containing new or non-standard functions.

[0106] In some embodiments, Figure 5 This is a third flowchart illustrating the data processing method for a feeder terminal provided in this application embodiment, as shown below. Figure 5 As shown, the step 101, "generating a user interface based on the attribute list, service list, and event list", can be achieved through the following steps 1014 to 1017.

[0107] In step 1014, a preset interface layout template is obtained, wherein the interface layout template includes a data monitoring area, a remote control area, and a real-time event sequence recording area.

[0108] Here, an interface layout template refers to a pre-designed, generic user interface framework that is independent of specific device models. It defines the overall structure of the interface and the division of different functional areas, but does not contain any specific device data or control buttons. It can be understood as a blank webpage or window template with placeholders such as "data monitoring area," "remote control area," and "event logging area."

[0109] Here, the data monitoring area is used to centrally display various status quantities and currently effective configuration quantities reported by the feeder terminal, allowing maintenance personnel to intuitively monitor the real-time status and operating parameters of the feeder terminal.

[0110] Here, the remote control area is used to place the entry point for all remote operation commands that can be executed on the feeder terminal. It is usually represented by a series of function buttons, which allow maintenance personnel to actively issue control commands.

[0111] Here, the real-time event sequence recording area is used to display, in chronological order, event information such as alarms, notifications and status changes actively reported by the feeder terminal, forming a traceable operation and fault log.

[0112] In step 1015, based on the attribute list, data display items are generated in the data monitoring area of ​​the interface layout template.

[0113] For example, assuming the attribute list is represented as [{"Function Name": "Phase A Current", "Category": "Status Quantity"}, {"Function Name": "Overcurrent Protection Setting", "Category": "Configuration Quantity"}], the following content is dynamically generated in the data monitoring area: For the "A-phase current" (state quantity), generate a read-only text display item to show its value in real time.

[0114] For the "overcurrent protection setting" (configuration value), generate a display item with a label and an editable input box, which can both display the current value and allow the user to modify it.

[0115] In step 1016, operation controls are generated in the remote control area of ​​the interface layout template based on the service list.

[0116] For example, assuming the service list is represented as [{"Service Name": "Remote Tripping"}, {"Service Name": "Device Reset"}], two buttons are dynamically generated in the remote control area of ​​the interface layout template: One button is labeled "Remote Trip".

[0117] The other button is labeled "Device Reset".

[0118] In step 1017, based on the event list, an event log display area is generated in the real-time event sequence recording area in the interface layout template to obtain the user operation interface. The event log display area is used to present the events in the event list.

[0119] For example, assuming the event list is represented as [{"Event Name": "Overcurrent Alarm Event"}], a log record is dynamically generated in the real-time event sequence recording area of ​​the interface layout template: [Overcurrent alarm event].

[0120] In the embodiments of this application, a preset interface layout template containing a data monitoring area, a remote control area, and a real-time event sequence recording area is obtained. Using the attribute list, service list, and event list generated in the preceding steps, data in the attribute list is precisely mapped to generate data display items and placed in the data monitoring area. Functions in the service list are precisely mapped to generate operation controls and placed in the remote control area. Simultaneously, information in the event list is precisely mapped to generate an event log display area and placed in the real-time event sequence recording area. This results in a user interface with a clear structure and well-defined functional partitions. This generation method, which maps data based on preset categories to preset template areas, automatically constructs a standardized interactive interface independent of specific device models. Because its functional layout strictly corresponds to the underlying data source, this standardized interactive interface ensures that maintenance personnel can intuitively and efficiently monitor data display, invoke remote services, and track real-time events, thereby significantly improving the accuracy and convenience of on-site maintenance operations.

[0121] In step 102, a preset operation and maintenance template is loaded through the user interface. The preset operation and maintenance template includes a test instruction sequence and a set of expected test results corresponding to the test instruction sequence.

[0122] Here, a pre-defined operations and maintenance template refers to a standardized, reusable electronic file or data package that encapsulates a complete operations and maintenance operation (such as a "remote point-to-point test"). This template does not refer to the layout of the user interface, but rather to an "operation plan" or "test script" that includes "what to do" (the sequence of test instructions) and "how to determine success" (the expected set of test results). When performing standardized tests, operations and maintenance personnel do not need to manually input instructions and judge results step by step; they can simply load the corresponding template to start the test with one click.

[0123] Here, a test command sequence refers to a pre-arranged series of remote operation commands that need to be sent sequentially to the feeder terminal to complete a specific test objective. For example, a test command sequence for a "switch opening / closing test" might include: Step 1: Send a "remote opening" command; Step 2: Wait 3 seconds; Step 3: Send a "remote closing" command. After loading the preset maintenance template, the system will automatically send commands to the feeder terminal step by step according to the test command sequence, without manual intervention.

[0124] Here, the expected test result set refers to one or more predefined criteria that mark the success of the test, corresponding to each step or the final result in the above-mentioned "test instruction sequence". For example, the expected test result set for the test instruction sequence corresponding to the "switch opening and closing test" might be as follows: for the first step "remote opening", a "switch position change" event is expected to be received, and the event content shows the new status as "open"; for the third step "remote closing", another "switch position change" event is expected to be received, and the new status as "closed".

[0125] In some embodiments, the preset operation and maintenance template can be a user-defined operation and maintenance template, that is, the preset operation and maintenance template can be generated by receiving the point table configuration information and test item sequence input by the user.

[0126] In some embodiments, the preset operation and maintenance template can be obtained in the following way: based on one or more historical operation and maintenance logs stored in the full lifecycle archive, the configuration of frequently accessed point tables is determined through a preset analysis algorithm, and a sequence of typical test items with a fixed order is identified, thereby automatically generating one or more recommended operation and maintenance templates, and selecting one of the one or more recommended operation and maintenance templates as the preset operation and maintenance template.

[0127] In some embodiments, the preset analysis algorithm may be an association rule mining algorithm (e.g., Apriori algorithm or FP-Growth algorithm) and a sequence pattern mining algorithm (e.g., GSP algorithm or PrefixSpan algorithm), etc.

[0128] In the embodiments of this application, information is directly extracted from historical operation and maintenance logs to objectively refine efficient operation combinations and processes that have been tested in practice. This avoids subjective preferences or omissions of key steps that may occur due to differences in personal experience when manually creating templates, significantly reducing the workload required to manually configure and design templates for different devices or tasks, and improving the efficiency of operation and maintenance preparation. Simultaneously, by generating recommended templates based on collective historical operation data, this approach promotes the standardization of operating procedures among different operation and maintenance personnel, ensuring the consistency and completeness of key testing processes.

[0129] In some embodiments, selecting one of the one or more recommended operation and maintenance templates as the preset operation and maintenance template can be achieved in the following way: after receiving the user's confirmation instruction for selecting one or more recommended operation and maintenance templates, the selected recommended operation and maintenance template is fixed as the preset operation and maintenance template.

[0130] In other embodiments, one of one or more recommended maintenance templates is selected as the preset maintenance template. This can be achieved by: comprehensively scoring each automatically generated recommended maintenance template based on preset dimensions other than historical maintenance logs. These preset dimensions may include: the matching degree with the device model of the feeder terminal to be maintained, the complexity of the recommended maintenance template (e.g., the number of point entries or test steps), and the relevance of the operation types covered by the recommended maintenance template to the current maintenance task objectives. In the embodiments of this application, by automatically calculating the comprehensive score of each recommended maintenance template and selecting the recommended maintenance template with the highest score, it is directly determined as the preset maintenance template, eliminating the need for manual user intervention and achieving a higher degree of automation.

[0131] In step 103, a test instruction sequence is sent to the feeder terminal to execute the test, and the test process information is recorded. The actual test result set obtained after the test is executed is compared with the expected test result set, and a debugging record report is generated based on the comparison results and the test process information.

[0132] Here, test process information refers to logs that record all interaction data during test execution in chronological order, including at least the sent test command messages, received response messages, and their respective timestamps.

[0133] Here, the actual test result set refers to the specific event or state data that corresponds to the expected test result set.

[0134] Here, the debug log report refers to a structured summary document that integrates all relevant information from this test.

[0135] In some embodiments, the test instruction sequence includes at least one test instruction. Step 103, "sending the test instruction sequence to the feeder terminal to execute the test and recording the test process information," can be achieved as follows: obtaining a test process information template; for each test instruction in the test instruction sequence, performing the following steps: encoding the current test instruction into a test instruction message based on a wireless communication protocol; encrypting the test instruction message using a preset session key, and sending the encrypted test instruction message to the feeder terminal via wireless communication; synchronously recording the sent test instruction message and the timestamp corresponding to the test instruction message in the test process information template; receiving the response message corresponding to the current test instruction returned by the feeder terminal, parsing the response message to obtain the actual test result corresponding to the current test instruction and the response result corresponding to the current test instruction, and synchronously recording the response result and the timestamp corresponding to the response result in the test process information template to obtain the test process information.

[0136] Here, a wireless communication protocol refers to a set of rules and conventions that precisely define the format, meaning, and order of data exchange between communicating parties.

[0137] For example, suppose maintenance personnel need to perform a "remote fault simulation and protection trip test" on a newly installed feeder terminal to verify whether its protection function is normal. The preset test command sequence is ["simulate phase A overcurrent fault", "query switch status"]. Wireless communication with the feeder terminal is conducted via Bluetooth. Both parties agree to use a simplified power industry protocol for data exchange, and the preset session key for this communication has been agreed upon as SessKey_FTU123.

[0138] When the test begins, an empty test process information template is first obtained. Logically, this empty test process information template is a log prepared to record all interaction data in chronological order.

[0139] For the first instruction in the test instruction sequence, "Simulate phase A overcurrent fault", execute the following series of automated steps: Encoding and Encryption: According to the agreed power industry protocol, the high-level command "simulate phase A overcurrent fault" is encoded into a hexadecimal message that the feeder terminal can directly parse, such as C101 0A F2. Then, the message is encrypted with AES using the session key SessKey_FTU123 to generate a string of encrypted data.

[0140] Sending and Recording: The encrypted message is sent to the feeder terminal via Bluetooth. At the same time, the original message C1 01 0A F2 (and its meaning "instruction: simulate A-phase overcurrent fault") and the current timestamp 14:20:05.110 are synchronously recorded in the test process information template as proof of the executed action.

[0141] Reception and Parsing: The feeder terminal receives data, decrypts it, and executes the command. After execution, it returns a response message. Upon receiving this response message, it decrypts and parses it. The parsing process may yield two types of information: one is an immediate response result, such as "command confirmed"; the other is the actual test result reported later by the protection logic, i.e., "protection action event, type: overcurrent trip".

[0142] Record the response: The parsed "response result" and its timestamp 14:20:05.350, as well as the "actual test result" and its timestamp 14:20:05.980, are also synchronously recorded in the test process information template.

[0143] For the second instruction, "Query switch status," the above process is repeated. The instruction is encoded as message D2 00 00B3, encrypted, and sent, with the sending information recorded. Subsequently, the message returned by the feeder terminal containing the current switch status is received and parsed to obtain the actual test result "Switch status: 0," which, along with the response result, is recorded in the template.

[0144] Once the entire sequence of test commands has been executed, the previously blank template has been filled with all the details of the interactions, ultimately yielding complete test process information. This information records the entire "dialogue" process of the test in detail and in an orderly manner, providing the most original and reliable data foundation for the subsequent generation of debug reports.

[0145] In some other embodiments, step 103, "sending a test instruction sequence to the feeder terminal to execute the test and recording the test process information," can be achieved as follows: Based on the attribute list and service list, for each general test instruction in the test instruction sequence, find and match its corresponding specific point table address or register address in the feeder terminal to obtain the mapped test instruction sequence; obtain the test process information template; for each test instruction in the mapped test instruction sequence, perform the following steps: For each address-mapped test instruction in the test instruction sequence, perform the following steps: Based on the wireless communication protocol, encode the current test instruction into a test instruction message; encrypt the test instruction message using a preset session key, and send the encrypted test instruction message to the feeder terminal via wireless communication; synchronously record the sent test instruction message and its corresponding timestamp in the test process information template; receive the response message corresponding to the current test instruction returned by the feeder terminal, parse the response message to obtain the actual test result and response result corresponding to the current test instruction, and synchronously record the response result and its corresponding timestamp in the test process information template to obtain the test process information.

[0146] In the embodiments of this application, a mapping step is added before sending test commands. This involves converting general test commands (e.g., "read phase A current") that are independent of specific devices in the maintenance template into specific operation commands (e.g., "read register at address 0x4001") based on the previously parsed attribute and service list. This mapping process establishes a conversion bridge between standardized, upper-level test logic and diverse, lower-level device implementations. This decouples the automated test logic from the specific feeder terminal's proprietary protocol, allowing the same maintenance template to be applied to feeder terminals from different manufacturers without modification. This significantly improves the versatility and portability of the automated test solution.

[0147] In some embodiments, the wireless communication method may be Bluetooth, WIFI, LoRa, Zigbee, etc.

[0148] In some embodiments, the wireless communication method can be matched with a wireless communication protocol to achieve optimal communication performance, lower technical implementation complexity, and better compatibility. For example, the wireless communication method may be Bluetooth, and the corresponding wireless communication protocol may be the Bluetooth unbalanced 101 protocol.

[0149] In the embodiments of this application, for each test instruction in the test instruction sequence, not only is the encoded test instruction message encrypted using a preset session key, but the sent test instruction message and the response message returned by the feeder terminal, along with their respective timestamps, are also synchronously recorded in the test process information template, ultimately obtaining a complete set of test process information. This method first ensures the confidentiality and integrity of the test instructions during wireless transmission through encrypted communication, effectively preventing the risk of eavesdropping or tampering. Simultaneously, by performing bidirectional recording with timestamps throughout the entire instruction interaction process, this method constructs a precise and traceable chain of test execution evidence. This chain of evidence not only faithfully reproduces every detail of the test but also provides an irrefutable data source for subsequent result comparison and report generation, thereby greatly improving the security of the automated testing process and the reliability of the test process information recording.

[0150] In some embodiments, Figure 6 This is a fourth flowchart illustrating the data processing method for a feeder terminal provided in this application embodiment, as shown below. Figure 6 As shown, in step 103, “compare the actual test result set obtained after the test with the expected test result set, and generate a debugging record report based on the comparison results and test process information” can be achieved through the following steps 1031 to 1033.

[0151] In step 1031, the actual test results corresponding to each test instruction are integrated to obtain the actual test result set.

[0152] Here, the actual test result refers to the core feedback information returned from the feeder terminal after executing a single test command, which can directly reflect the execution status of the command. It is usually expressed as a specific event report, a status value, or a confirmation response.

[0153] In some embodiments, the test process information includes a test instruction message, a timestamp corresponding to the test instruction message, a response result, and a timestamp corresponding to the response result. The actual test result corresponding to each test instruction can be obtained in the following way: locate the test instruction message corresponding to the current test instruction and the timestamp corresponding to the test instruction message; use the timestamp corresponding to the test instruction message as a reference to find all response results with timestamps later than the reference; examine these found response results, identify and extract one or more response results that can characterize the final effect of the instruction execution, and use them as the actual test result corresponding to the current test instruction to obtain the actual test result corresponding to each test instruction.

[0154] In step 1032, the actual test result set is compared with the expected test result set to obtain the comparison result.

[0155] In step 1033, the test process information and comparison results are integrated to generate a debug record report.

[0156] For example, suppose a "remote switch opening / closing" test includes two commands: ["remote opening", "remote closing"]. First, obtain the actual test result corresponding to the first command, "remote opening", which is "Event: switch position change, new state: open". Then, obtain the actual test result corresponding to the second command, "remote closing", which is "Event: switch position change, new state: closed". By integrating these two independent actual test results, a complete set of actual test results is obtained: ["Event: switch position change (open)", "Event: switch position change (close)"].

[0157] The actual test result set obtained in the previous step is compared with the expected test result set ["Expected state: quantile", "Expected state: synergy"] preset in the operation and maintenance template. The comparison process reveals that the "quantiles" in the actual results match the expected "quantiles", and the "synergies" in the actual results also match the expected "synergies". Based on this, the comparison result is: "Test passed, all results meet expectations".

[0158] The complete test process information (i.e., detailed logs including timestamps and message content of all sent commands and received responses) is integrated with the comparison result obtained in the previous step ("Test passed, all results meet expectations"). By merging and formatting these two parts of information, a well-structured debug log report is finally generated.

[0159] In the embodiments of this application, the isolated actual test results corresponding to each test instruction are first integrated to form a structured set of actual test results. Then, this set of actual test results is automatically compared item by item with a preset set of expected test results to obtain a clear comparison result. Finally, this comparison result is merged with test process information that records the complete interaction process to generate a final debug log report. This method implements a data processing mechanism that tightly binds the test execution process with the test conclusion judgment. The generated debug log report not only includes the final judgment of whether the test passed or failed, but also includes complete, timestamped instruction interaction evidence that led to that judgment. This provides maintenance personnel with a comprehensive report that requires no secondary analysis, is both conclusive and traceable, greatly improving the efficiency and reliability of automated test result analysis.

[0160] In step 104, maintenance operations are performed on the feeder terminal through the user interface, and maintenance logs are generated based on the maintenance operations and their response results.

[0161] Here, "operation and maintenance operation" refers to a single, immediate command initiated by operation and maintenance personnel through the user interface to the feeder terminal to achieve specific management functions such as real-time monitoring, parameter configuration, or manual control.

[0162] Here, the response result of an operation and maintenance operation refers to the data information returned by the feeder terminal to the user interface after receiving and executing an operation and maintenance operation, which can directly reflect the execution status of the operation or the content of the query, such as a "successful execution" confirmation status or a real-time current value being queried.

[0163] Here, the operation and maintenance log refers to a structured log list that is automatically generated with timestamps based on all operation and maintenance operations performed by the user and their response results, and is used to record and trace the history of manual intervention.

[0164] In some embodiments, maintenance operations may include reading real-time telemetry data, performing remote device reset, modifying protection setting parameters, or retrieving historical fault recording files.

[0165] In some embodiments, Figure 7 This is a fifth flowchart illustrating the data processing method for a feeder terminal provided in this application embodiment, as shown below. Figure 7 As shown, step 104 can be achieved through the following steps 1041 to 1044.

[0166] In step 1041, the operation and maintenance operation instructions corresponding to the operation and maintenance operation are obtained, and the operation and maintenance operation instructions are converted into operation and maintenance operation messages based on the wireless communication protocol.

[0167] Here, maintenance operation messages refer to data sequences generated by encoding maintenance operation instructions according to a specific wireless communication protocol format, which can be directly transmitted in the communication channel and can be parsed and executed by the device.

[0168] For example, maintenance personnel might perform a maintenance operation via the interface to "calibrate device time," inputting the target time "2023-10-27 15:30:00." The system retrieves the corresponding maintenance operation instruction, namely the "time synchronization" instruction, along with its parameter "2023-10-27 15:30:00." Subsequently, based on a preset wireless communication protocol (such as a simplified DL / T645 protocol), this instruction is converted into a hexadecimal maintenance operation message, such as FE FE 68 1A...33 30 15 27 10 230C...16. This message contains a start-of-frame character, device address, function code (representing "time synchronization"), data length, data content (time represented in BCD code), a checksum, and an end-of-frame character, and can be directly transmitted via the wireless channel.

[0169] In step 1042, the operation and maintenance message is encrypted using a preset session key, and the encrypted operation and maintenance message is sent to the feeder terminal via wireless communication.

[0170] In step 1043, the operation and maintenance response message returned by the feeder terminal is received, and the operation and maintenance response message is parsed to obtain the response result of the operation and maintenance operation.

[0171] Here, the maintenance response message refers to the data sequence generated by the feeder terminal when it successfully executes a maintenance operation or is preparing to return query data, according to the agreed wireless communication protocol, after encoding the execution status or data content, and is used to feed back information to the host computer.

[0172] Following the example above, a hexadecimal data segment (i.e., maintenance response message) FEFE 68 81...00...16 is received from the feeder terminal, and the maintenance response message is parsed: the parsing reveals that function code 81, according to the protocol definition, represents "operation success confirmation", and the response result of this maintenance operation of "calibrating equipment time" is obtained, that is, "execution successful".

[0173] In step 1044, the operation and maintenance operations and their response results are recorded to obtain the operation and maintenance log.

[0174] In the embodiments of this application, an operation and maintenance (O&M) operation instruction corresponding to an O&M operation is converted into an O&M operation message. This message is then encrypted using a preset session key and sent to the feeder terminal via wireless communication. Upon receiving the O&M response message from the feeder terminal, the parsed response result is associated with the initial O&M operation and recorded, ultimately generating an O&M log. This method ensures the security of manual O&M instructions over the air through encrypted transmission, preventing the risk of malicious interference or unauthorized operations. Simultaneously, by binding and recording the operation instructions with the response results returned by the device, a closed-loop log recording mechanism with a one-to-one correspondence between operation and result is constructed. This ensures that the generated O&M log not only faithfully reflects the operation intent but also accurately reflects the actual execution feedback from the feeder terminal, greatly improving the traceability and audit reliability of the manual O&M process.

[0175] In step 105, the debugging record report and operation and maintenance log are integrated to obtain the full life cycle archive of the feeder terminal.

[0176] Here, the full lifecycle archive refers to a comprehensive collection of records arranged in chronological order, which includes debugging records, reports, and operation and maintenance logs.

[0177] In the embodiments of this application, a standardized user interface is generated by parsing the device model file of the feeder terminal using a preset object model. A preset operation and maintenance template containing a test instruction sequence and a set of expected test results is loaded, and instructions are automatically sent to the feeder terminal to execute tests, compare results, and generate debugging record reports. This achieves standardized operation and automated testing of the feeder terminal, improving the efficiency and standardization of operation and maintenance work. At the same time, this application integrates the generated debugging record reports with the operation and maintenance logs generated by manual operation and maintenance operations, and finally obtains a full lifecycle archive associated with a specific feeder terminal. This constructs a systematic data integration and management mechanism, providing a complete data foundation for subsequent data traceability and analysis, and improving the level of data management.

[0178] In some embodiments, to facilitate subsequent multi-dimensional data analysis and mining, the storage of the entire lifecycle archive can employ dimensional data modeling techniques. For example, a star schema or snowflake schema can be constructed with maintenance events as the core facts and time, equipment information, operators, geographical location, etc., as dimensions. This allows for the structured storage of data such as debugging records, maintenance logs, and fault events, significantly improving the efficiency of performing correlation queries and performance trend analysis on massive amounts of historical data.

[0179] In some embodiments, Figure 8 This is a sixth flowchart illustrating the data processing method for a feeder terminal provided in this application embodiment, as shown below. Figure 8 As shown, step 105 can be achieved through the following steps 1051 to 1053.

[0180] In step 1051, the initial test report and identification of the feeder terminal are obtained, and an archive file is created based on the identification.

[0181] Here, the initial test report refers to the official document generated by the manufacturer or quality inspection unit after a series of standardized tests are completed before the feeder terminal leaves the factory or is put into use. It records the hardware configuration, firmware version, basic function verification results and key performance indicator test values.

[0182] Here, an identification identifier refers to a string or code that can uniquely and permanently distinguish each individual feeder terminal, such as the device's serial number (SN), MAC address, or internal unique identifier.

[0183] Here, an archive file refers to a structured electronic data container created based on the identity of a specific feeder terminal, used to centrally store and manage all relevant historical records of that terminal from its initial state to its subsequent history.

[0184] In step 1052, the initial performance data in the initial test report is used as baseline data and stored in the archive file.

[0185] Here, initial performance data refers to a set of key performance indicators extracted from the initial test report that can quantify the core functional performance of the feeder terminal in its factory state, such as the response time of specific commands, the acquisition accuracy of telemetry, and the inherent delay of opening and closing actions.

[0186] In some embodiments, the initial test report may be a factory test report, a test report from the China Electric Power Research Institute, or a combination of a factory test report and a test report from the China Electric Power Research Institute.

[0187] In step 1053, the debugging record report and operation and maintenance log are stored in the archive file in chronological order to obtain the full life cycle archive.

[0188] In the embodiments of this application, a unique archive file is first created based on the identity of the feeder terminal. Then, the initial performance data from the initial test report is extracted and stored in the archive file as baseline data. Finally, debug log reports recording the automated testing process and conclusions, and operation and maintenance logs recording manual maintenance operations and feedback are continuously appended to the archive file in chronological order, ultimately resulting in a complete full lifecycle archive. This method systematically integrates debug records (reflecting the real-time status of the equipment under controlled testing), operation and maintenance logs (recording the manual intervention process), and optional fault records (capturing sudden events during operation), filling the gaps of data dispersion and fragmentation in the traditional offline operation and maintenance mode. Thus, when performing fault analysis, it can accurately distinguish whether the root cause of the problem is an inherent defect of the equipment (which can be determined by tracing back the baseline data in the initial test report), improper parameter settings (which can be checked in the modification records in the operation and maintenance logs), or caused by external power grid events. It effectively solves the technical pain point of unclear fault causes caused by data gaps in traditional operation and maintenance, and provides a complete data chain for accurate problem location.

[0189] In some other embodiments, step 105 can be implemented by: obtaining the initial performance report of the feeder terminal; integrating the initial performance report, debugging record report and operation and maintenance log to obtain the full life cycle archive of the feeder terminal.

[0190] In the embodiments of this application, the initial performance report, debugging record report, and operation and maintenance log of the feeder terminal are integrated to form a complete archive capable of tracing the evolution of the device's state. The initial performance report provides a definite raw data benchmark for all subsequent performance evaluations of the device. The debugging record report records the device's functional response under automated testing, while the operation and maintenance log records the history of manual operations during actual operation. Combining these three types of information from different sources but continuous in time allows for precise differentiation, when analyzing the current state of any device, between the inherent factory performance of the feeder terminal, subsequent functional logic execution errors, and specific human intervention. This clear attribution capability eliminates the need for speculation in the troubleshooting process, directly improving the accuracy of operation and maintenance work, and providing objective and complete data support for assessing the long-term health of the feeder terminal and formulating maintenance strategies.

[0191] In other embodiments, step 105 can also be implemented in the following way: receiving event messages actively reported by the feeder terminal based on the event list, parsing the event messages, generating a fault record when the event message is a fault event, and obtaining the full lifecycle archive of the feeder terminal by integrating the debugging record report, operation and maintenance log and fault event.

[0192] Here, an event message refers to a structured data frame that a feeder terminal actively packages and reports according to a predefined communication protocol and physical model specification when its internal state changes or it detects a sudden change in the external power grid state, without the need for external command queries.

[0193] For example, a typical event message may contain one or more of the following information: Remote signal change event (SOE / COS): When a switch position changes from "closed" to "open", the feeder terminal will actively report an event message, the content of which may be: "[timestamp: 2024-11-06 14:30:25.123] [information body address: 0x0001][status: 0 (open position)]".

[0194] Protection action event: When the line current exceeds the set value (overcurrent) and the circuit breaker is tripped, the feeder terminal will report an event message, the content of which may be: "[Timestamp: 2024-11-06 15:02:10.555] [Event type: Overcurrent Stage II action] [Fault phase: Phase A] [Action value: 1050A]".

[0195] Equipment self-alarm event: When the feeder terminal detects an abnormality through self-diagnosis, it will report an event message, such as: "[Timestamp: 2024-11-06 16:15:00.010] [Event type: Low battery voltage alarm] [Current value: 22.5V]".

[0196] Fault Information Reporting Event: When a power grid fault is captured and successfully recorded, the feeder terminal will report an event message to notify that "a new fault recording file has been generated". The content may be: "[Timestamp: 2024-11-06 15:02:11.000] [Event Type: Fault Recording File Generation Notification] [File Name: Fault_20241106150210.dat]".

[0197] In the embodiments of this application, a more comprehensive full lifecycle archive is constructed by integrating the feeder terminal's commissioning record report, operation and maintenance log, and fault records proactively reported by the terminal. The commissioning record report verifies the feeder terminal's functional completeness under preset scenarios, while the operation and maintenance log fully records all planned manual operations and equipment responses. The introduced fault records capture snapshots of unexpected emergencies encountered by the feeder terminal during operation, filling data gaps that cannot be covered by commissioning and operation and maintenance information alone. Combining these three elements allows for a clear distinction in post-event analysis between whether a change in equipment status stems from deviations in functional logic execution (i.e., commissioning records), the result of specific manual intervention (i.e., operation and maintenance logs), or is triggered by a real fault in the external power grid (i.e., fault records). This significantly enhanced attribution capability not only makes routine problem troubleshooting more accurate but, more importantly, provides direct, high-value field data for understanding and reproducing real, sporadic power grid faults, thus providing a solid and reliable basis for optimizing protection strategies and improving the fault adaptability of feeder terminals.

[0198] In some embodiments, the system receives event messages actively reported by the feeder terminal based on an event list and parses the event messages. When the event message is a fault event, a fault record is generated. This includes: continuously monitoring the wireless communication channel with the feeder terminal to receive event messages reported by the feeder terminal; parsing the received event messages to extract the event type and event content; determining whether the event type belongs to a preset set of fault event types; and when the determination result is yes, integrating the event content, the event occurrence timestamp, and the event type to generate a fault record.

[0199] In some embodiments, Figure 9 This is a seventh flowchart illustrating the data processing method for a feeder terminal provided in this application embodiment, as shown below. Figure 9 Before step 101, steps 106 to 108 may also be performed.

[0200] In step 106, a first authentication request is sent to the feeder terminal.

[0201] In step 107, the response results of the second authentication request and the first authentication request returned by the feeder terminal are received, wherein the second authentication request includes the identity identifier of the feeder terminal.

[0202] In step 108, when the response to the first authentication request is correct and the identity of the feeder terminal is valid, a preset session key is generated, and an encrypted wireless communication connection with the feeder terminal is established using the preset session key.

[0203] It should be noted that the response result of the first authentication request includes whether the feeder terminal verifies that the first authentication request is valid or invalid. When the first authentication request is valid, the response result of the first authentication request is correct; when the first authentication request is invalid, the response result of the first authentication request is incorrect.

[0204] In the embodiments of this application, a first authentication request is first sent to the feeder terminal. Upon receiving a second authentication request from the feeder terminal containing its identity identifier, along with the response to the first authentication request, dual verification is performed. This involves simultaneously determining whether the response to the first authentication request is correct and whether the feeder terminal's identity identifier is legitimate. Only when both conditions are met is a preset session key generated. This bidirectional request and response authentication mechanism changes the unidirectional mode where only one party initiates authentication. It requires both communicating parties to simultaneously verify each other's legitimacy before key negotiation can be completed and subsequent steps can proceed. This mechanism ensures that only legitimate feeder terminals that have undergone strict dual verification of identity and permissions can establish an encrypted wireless communication connection, thereby fundamentally avoiding the risk of unauthorized device access or legitimate device impersonation, and greatly enhancing the security of identity authentication before the establishment of the wireless communication link.

[0205] In practice, the electronic device can send a first authentication request to the feeder terminal. The first authentication request may include the identity identifier of the electronic device. At this time, if the feeder terminal verifies that the first authentication request is valid, it means that the feeder terminal verifies that the identity identifier of the electronic device is valid. If the feeder terminal verifies that the first authentication request is invalid, it means that the feeder terminal verifies that the identity identifier of the electronic device is invalid.

[0206] In some embodiments, after step 105, the following steps may also be performed: based on the debugging record reports, operation and maintenance logs and fault records integrated in the full life cycle archive, a preset data mining algorithm is used to train and construct an evaluation model for assessing the health status of the feeder terminal.

[0207] Here, the predefined data mining algorithm refers to specific mathematical and statistical methods applied to full lifecycle archive data to discover hidden patterns, correlations, and trends. The choice of algorithm depends on the specific evaluation objectives and data characteristics.

[0208] For example, the preset data mining algorithm may include, but is not limited to: Classification algorithms (such as Support Vector Machines (SVM), decision trees, or logistic regression) are used to determine whether a device's current health status belongs to a predefined category, such as "healthy," "sub-healthy," or "high-risk for failure." For example, by analyzing historical fault records and maintenance logs, a decision tree can learn that "battery voltage below 23V and remote signaling false alarms exceeding 5 times in the past month" are the main patterns causing device communication interruptions.

[0209] Regression algorithms (such as linear regression and gradient boosting tree GBDT) are used to predict the continuous value of a key performance indicator of a device in the future, such as predicting "remaining battery life in the next 30 days" or "the decreasing trend of insulation resistance".

[0210] Clustering algorithms (such as K-Means) are used to automatically group devices with similar behavioral patterns without prior labeling. For example, the operation logs and fault records of a large number of devices can be clustered to automatically discover a group of devices with common problems such as "frequent self-recovery" or "communication interruption", thereby enabling targeted troubleshooting.

[0211] Association rule algorithms (such as Apriori) are used to discover interesting relationships between different events. For example, they can discover strong association rules such as "During the summer thunderstorm season, the probability of 'power module failure' and 'communication interruption' events occurring simultaneously for FTU of model A is as high as 80%".

[0212] Here, the feeder terminal health status assessment model refers to the final output obtained after training historical data using the aforementioned data mining algorithm, which can automatically assess and predict new and unknown feeder terminal data. Essentially, it is a "mathematical function" or "rule set" that encapsulates knowledge learned from data, receiving current and historical data from the device as input and outputting an assessment result of its health status.

[0213] For example, the evaluation model can be specifically represented as: A health scoring function: Inputting the full lifecycle profile data of a feeder terminal, the model outputs a health score from 0 to 100, with higher scores indicating better device condition. Maintenance personnel can set a threshold (e.g., 60 points); devices scoring below this threshold will be prioritized for maintenance.

[0214] A fault prediction classifier: Input the recent operating data of a feeder terminal, and the model outputs the probability that a specific fault (such as "communication interruption" or "false alarm") will occur within the next week.

[0215] An anomaly pattern recognizer: This model is trained to identify normal device behavior patterns. When a feeder terminal's real-time data stream deviates from these normal patterns, the model triggers an "abnormal operating status" alarm, even if the anomaly does not constitute a clear fault.

[0216] In the embodiments of this application, after integrating the full lifecycle archive, a health status assessment model based on data mining technology is further introduced, realizing a leap from "post-event tracing" to "pre-event prediction." The full lifecycle archive can only provide a faithful record of events that have occurred, while the feeder terminal health status assessment model constructed in this application can proactively analyze the complex correlations hidden in these historical records, such as the correlation between specific maintenance operations and subsequent failure events, or the causal chain between certain minor performance parameter drifts and eventual equipment failure. This capability allows feeder terminal maintenance to go beyond simply responding to existing failures; it enables the predictive identification of individuals in a "sub-healthy" state or with a high risk of failure based on the health score or failure probability output by the model. In this way, the allocation of maintenance resources can shift from a passive, uniform inspection mode to a proactive, differentiated, and precise maintenance mode, significantly improving the predictability and efficiency of maintenance work and providing a deeper level of assurance for the reliable operation of feeder terminals.

[0217] In some embodiments, before step 101, the following steps may also be performed: reading the first unique serial number of the first hardware encryption chip built into the electronic device; encapsulating the first unique serial number in the first authentication request and sending it; receiving the second authentication request returned by the feeder terminal, which encapsulates the second unique serial number of its built-in second hardware encryption chip; and after verifying that both the first unique serial number and the second unique serial number are valid, negotiating and generating a preset session key using the first hardware encryption chip and the second hardware encryption chip.

[0218] In the embodiments of this application, hardware-level authentication is achieved by binding the authentication process to the unique serial number of the hardware encryption chip embedded in both communicating parties. Compared to purely software-level authentication, this method utilizes the immutability of the hardware serial number, greatly improving the reliability of identity recognition. Furthermore, the key negotiation and generation process can be completed by the hardware encryption chip executing a key exchange protocol (such as a key exchange protocol based on Chinese national cryptographic algorithms). This process utilizes cryptographic principles, enabling the two communicating parties to securely establish a shared session key over an insecure channel. Since the key generation operation is completed internally by the hardware encryption chip, rather than in a general-purpose processor, this ensures the confidentiality of the key negotiation process, prevents critical information from being stolen during the generation process, and thus provides a more robust security foundation for the entire wireless communication link.

[0219] In some embodiments, after verifying that both the first unique serial number and the second unique serial number are valid, a preset session key is negotiated and generated using the first hardware encryption chip and the second hardware encryption chip. This includes: the electronic device using its built-in first hardware encryption chip to generate a first key pair including a first public key and a first private key, wherein the first private key is securely stored inside the first hardware encryption chip; sending the first public key to the feeder terminal and receiving the second public key generated by the feeder terminal using its built-in second hardware encryption chip; using the first hardware encryption chip, based on the first private key stored inside and the received second public key, performing an asymmetric encryption operation to calculate a shared secret; and generating a preset session key for this communication based on the shared secret through a preset key derivation function.

[0220] In the embodiments of this application, end-to-end secure key generation is achieved by placing the core key negotiation operation within a hardware encryption chip. Specifically, since the private key never leaves the security boundary of the hardware encryption chip throughout its entire lifecycle from generation to use, the risk of malicious software stealing the private key from memory or storage is fundamentally eliminated. Furthermore, critical calculations such as asymmetric encryption and key derivation are also performed by hardware. This not only ensures the isolation and atomicity of the key generation process, effectively resisting attacks from the operating system level, but also leverages the high performance of the hardware to improve the efficiency of key negotiation, while providing a solid security foundation for subsequent encrypted communication of business data.

[0221] The data processing method for feeder terminals provided in this application can be applied to multiple electronic devices to achieve collaborative operations and real-time data consistency in complex operation and maintenance scenarios. Taking a handheld operation and maintenance terminal (hereinafter referred to as "terminal") as an example, the collaborative working mode of multiple terminals can specifically include the following steps: One terminal (master terminal) initiates a collaborative mode and creates a temporary local operation network through local wireless communication technology (such as Wi-Fi Direct or Bluetooth). Other terminals (slave terminals) join the network to form a collaborative work group. The master terminal broadcasts a complete copy of the currently loaded object model and full lifecycle file for the target feeder terminal to all slave terminals in the work group, ensuring that all participating terminals operate based on a completely consistent device model and historical data. Any terminal in the work group can independently perform operation and maintenance operations on the feeder terminal. For example, one terminal is responsible for monitoring real-time changes in status variables, another terminal is responsible for modifying the set values ​​of configuration variables, and a third terminal can execute an independent test project. All operations are conducted through the master terminal or directly with the feeder terminal. When any terminal's operation causes a change in the feeder terminal's state (such as updating status variables or modifying configuration variables), or after performing an operation, this change information and operation log are broadcast in real time within the local work network. Upon receiving this information, all other terminals in the workgroup immediately refresh their loaded object model instances and operation interfaces to ensure that the device status seen by all operators is completely synchronized. After the collaborative operation is completed, all operation logs from the slave terminals are aggregated to the master terminal and uniformly recorded in the feeder terminal's full lifecycle archive, forming a complete, multi-perspective operation and maintenance report containing all personnel operations.

[0222] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0223] In modern power distribution automation systems, feeder terminal units (FTUs), as key nodes distributed extensively throughout the power distribution network, undertake core functions such as data acquisition, status monitoring, remote control, and fault protection. To ensure the safe and stable operation of the power distribution network, efficient, standardized, and safe operation and maintenance management of FTUs throughout their entire lifecycle, from factory installation and commissioning to daily operation, is crucial.

[0224] In related technologies, on-site maintenance of FTUs typically involves maintenance personnel carrying portable computers or manufacturer-specific maintenance tools, and physically connecting to the FTU installed on the utility pole via a wired connection (such as a serial port or Ethernet port). Maintenance personnel must manually input a series of test commands according to the paper or electronic debugging manual and the respective manufacturer's dedicated maintenance software interface. They then visually verify whether the data returned by the FTU matches the expected results and manually record the debugging process and results.

[0225] However, when faced with a large number of FTU devices from diverse manufacturers and brands, and installed in harsh environments, the aforementioned traditional operation and maintenance methods have exposed several key problems, mainly in the following aspects: (1) Heterogeneous operation and maintenance tools and outdated connection methods: The current operation and maintenance work relies heavily on the dedicated maintenance software bundled by the manufacturer, which requires operation and maintenance personnel to install and master dozens of tools with very different operations on the same terminal, forming "software islands" and increasing training costs and workload. At the same time, operation and maintenance must be carried out through wired connection, which is not only cumbersome to operate, but also forces operation and maintenance personnel to frequently perform high-risk pole climbing operations, which poses great safety hazards, especially in bad weather.

[0226] (2) Lack of manual and standardized commissioning process: Core commissioning steps such as on-site joint commissioning and parameter configuration rely entirely on manual input and visual comparison by maintenance personnel. This process is not only time-consuming and labor-intensive, but also inefficient, with low standardization, and is prone to errors due to differences in personnel experience or operational negligence. In addition, traditional joint commissioning methods also rely on the cooperation of standard source equipment, which further increases the complexity and limitations of on-site operations.

[0227] (3) Discretization of Operation and Maintenance Data and Disruption of Value Chain: Throughout the entire lifecycle of equipment, key data such as debugging records and operation logs generated from factory testing and network access testing to on-site debugging, maintenance, and fault handling are usually stored in the portable devices of on-site personnel in unstructured and scattered file form or are directly lost. These data cannot be strongly correlated with the lifecycle of specific equipment, resulting in a break in the management chain and making it difficult to form a full lifecycle archive of equipment from commissioning to scrapping. This greatly limits the ability to conduct long-term status tracking, fault root cause tracing, and health status assessment of equipment.

[0228] In view of this, embodiments of this application provide a data processing method for an FTU, which constructs a comprehensive solution integrating secure wireless communication, a unified platform, automated templates, and full lifecycle management. This method first establishes a secure wireless maintenance channel via Bluetooth communication with bidirectional authentication based on an encrypted chip, enabling safe ground operations without climbing poles and fundamentally solving the risks of high-altitude operations caused by wired connections. Secondly, it uses a standardized object model to uniformly abstract equipment from different manufacturers, generating a unified user interface and achieving "one-machine maintenance," resolving platform isolation issues caused by software heterogeneity. Thirdly, by loading customizable maintenance templates and combining them with scripts, it achieves automated joint debugging, transforming the debugging process, which relied on manual and standard sources, into an automated and standardized workflow, ensuring high efficiency and reliability of testing. Finally, it systematically integrates the debugging record reports generated by automated testing with the maintenance logs generated by manual maintenance, and supports the import of external data such as factory and electrical research institute test reports, forming a full lifecycle archive bound to the unique identifier of the equipment. This solves the management challenges of data fragmentation and value chain disruption, providing a solid data foundation for refined management and intelligent analysis of the entire equipment lifecycle, and significantly improving the maintenance efficiency, security, and management level of FTUs.

[0229] The FTU data processing system provided in this application includes: a unified maintenance software platform, a common component module, a data management module, a communication management module, and a back-end management system. The common component module, the data management module, and the communication management module are jointly deployed on a handheld terminal hardware, which integrates a Bluetooth communication module, an encryption chip, GPS, and a touch screen.

[0230] The unified maintenance software platform is responsible for human-computer interaction and business logic processing. It receives user operation and maintenance instructions, calls the functions of other modules, and presents the processing results to the user through a graphical interface, specifically providing operation entry points such as remote data acquisition, parameter configuration, historical data reading, and access control.

[0231] The common component module provides reusable basic functional components to support the development and operation of upper-layer application services. It includes UI components, data management components, security components, and logging components, aiming to improve code reusability, reduce software development and maintenance costs, and ensure intuitive and easy-to-use interface design.

[0232] The data management module is responsible for the structured definition, storage, and management of various types of data during operation, serving as the data foundation for interaction between various functional modules. Specifically, it manages real-time data (such as remote telemetry, remote sensing, and remote control data), historical data (such as SOE records), operation and maintenance records (used to build equipment maintenance archives), and customizable operation and maintenance templates, ultimately constructing a full lifecycle management model.

[0233] The communication management module is responsible for providing communication services between the handheld terminal and external devices (such as the FTU) and the backend system. It supports wired connections with the FTU via Ethernet / serial ports and, importantly, Bluetooth wireless communication based on bidirectional authentication using an encrypted chip, to establish a secure and reliable wireless operation and maintenance channel. Simultaneously, this communication management module also reserves communication interfaces (such as the MQTT protocol) for data synchronization with the backend management system.

[0234] The back-end management system is responsible for receiving maintenance record data synchronously from various handheld terminals, uniformly managing and distributing maintenance templates for FTUs of different manufacturers and models, and centrally storing, integrating and analyzing the full lifecycle archives to provide data support for preventive maintenance and fault diagnosis of feeder terminals.

[0235] Figure 10 This is a flowchart illustrating the data processing method for the feeder terminal provided in this application embodiment, in a field operation scenario where the handheld terminal hardware and the back-end management system work together. The following will combine... Figure 10 The steps shown illustrate the specific implementation process of the data processing method for the feeder terminal provided in the embodiments of this application.

[0236] In step 201, the background management system pre-sets and manages a unified object model and operation and maintenance template, and the handheld terminal hardware initiates a secure wireless connection with the target feeder terminal.

[0237] The backend management system pre-stores standardized, preset object models covering various manufacturers and models of FTUs. These preset object models abstract the functions of the FTU in the digital world into three categories: attributes (such as switch positions, voltage and current values ​​describing equipment status), services (such as remote opening and closing functions and parameter setting), and events (such as fault alarms and SOE information proactively reported by the equipment). The backend management system also stores various preset operation and maintenance templates. These templates are script files that authorized users can customize and configure through the backend management system. Their content includes test instruction sequences conforming to the DL / T634.5101 / 5104 power industry standards for automated testing, as well as a set of expected test results corresponding to each test instruction sequence.

[0238] When on-site maintenance personnel arrive at the work site carrying a handheld terminal hardware integrating a Bluetooth communication module, encryption chip, GPS, and touchscreen, the handheld terminal hardware activates its Bluetooth scanning function through its communication management module to search for nearby target FTUs. After the user selects a target FTU, the handheld terminal hardware's communication management module initiates a connection request with the FTU's built-in encrypted Bluetooth module. Both parties perform two-way authentication using their respective integrated national cryptographic algorithm encryption chips. The authentication process includes exchanging and verifying the encryption chip serial numbers to ensure the legitimacy and security of the connection. After successful authentication, both parties establish a fully encrypted wireless communication link based on the Bluetooth unbalanced 101 protocol, thereby enabling secure ground maintenance operations without the need for climbing poles.

[0239] In step 202, the handheld terminal hardware analyzes the feeder terminal based on the downloaded preset object model and generates a unified user interface.

[0240] After the wireless connection is established, the handheld terminal hardware sends instructions to the target FTU through its communication management module to read the target FTU's device identifier and model information. Subsequently, the handheld terminal hardware sends a request to the backend management system to report the device identifier and model information. Based on this information, the backend management system retrieves the most matching preset object model from its repository and sends the most matching preset object model to the handheld terminal hardware.

[0241] After receiving the preset object model, the handheld terminal hardware uses this preset object model to perform deep analysis of the FTU's device model file (usually a manufacturer-defined parameter configuration file). Specifically, the analysis process involves mapping each data point in the device model file to the attributes, services, and event definitions of the preset object model, thereby obtaining a structured list of attributes, services, and events specific to the FTU. Finally, the UI component in the common component module of the handheld terminal hardware dynamically and automatically generates a standardized, manufacturer-independent unified maintenance software platform user interface based on these lists. This unified maintenance software platform user interface intuitively displays all observable and controllable items of the FTU, achieving "one-stop maintenance" for equipment from different manufacturers.

[0242] In step 203, the handheld terminal hardware loads the operation and maintenance template and performs automated joint debugging point-to-point testing to generate a structured debugging record report.

[0243] Operation and maintenance personnel can select and load a preset operation and maintenance template suitable for the current task (such as commissioning and acceptance) through the user interface of the unified maintenance software platform. This operation and maintenance template can be downloaded in advance from the back-end management system to the local handheld terminal hardware.

[0244] The handheld terminal hardware parses the preset maintenance template, extracting the test command sequence and expected test result set defined by customized scripts. Subsequently, through its communication management module, the handheld terminal hardware automatically and sequentially sends the test command sequence to the FTU to execute automated testing, following the Bluetooth unbalanced 101 protocol. This process requires no traditional standard source. During testing, the handheld terminal hardware meticulously records the transmission time, content, and FTU response information for each command. After testing, the handheld terminal hardware automatically compares the actual test result set obtained from the FTU with the expected test result set defined in the preset maintenance template. Finally, based on detailed comparison results (success, failure, or anomaly) and complete test process information, a structured debug log report is generated locally. This report details all test items, processes, results, and conclusions, ensuring the traceability and accuracy of the debugging process.

[0245] In step 204, the handheld terminal hardware records manual operation and maintenance and generates operation and maintenance logs, providing process data for the full lifecycle archive.

[0246] Maintenance personnel can manually perform maintenance operations on the FTU through the user interface of the unified maintenance software platform. These operations include collecting and monitoring real-time remote data (remote signaling, telemetry, and remote control), querying and modifying key parameters and protection settings, and retrieving historical files (such as SOE records and operation logs).

[0247] During each manual maintenance operation, the handheld terminal hardware records all operation details through its data management module. This includes operator information, operation time, the specific maintenance operation performed (e.g., "modify the overcurrent stage I setting of phase A from 5A to 6A"), and the response result of the FTU triggered by the maintenance operation (e.g., "setup successful"). After a series of manual maintenance tasks are completed, the handheld terminal hardware integrates these records and generates a structured maintenance log locally.

[0248] In step 205, the back-end management system integrates multi-source data and finally builds and updates the full lifecycle archive of the feeder terminal.

[0249] After the maintenance task is completed, the handheld terminal hardware, through its communication management module, uses the reserved Message Queuing Telemetry Transport (MQTT) protocol communication interface to upload all the debugging record reports and maintenance logs generated locally during this task, along with the geographical location information obtained through the Global Positioning System (GPS) module, to the backend management system.

[0250] After receiving this data, the backend management system performs final data integration within its internal dimensional data model based on the FTU's unique device ID. First, the system checks if a full lifecycle file already exists for that device ID. If not, a new file is created, using the uploaded data as the initial record. If the file already exists, newly received commissioning reports and maintenance logs are appended to it in timestamp order. Furthermore, the system supports importing external data generated by the FTU at other stages, such as factory inspection reports and CETC (China Electric Power Research Institute) network access inspection reports, through specific interfaces. By integrating automated commissioning data, manual maintenance data, and authoritative external testing data, the system ultimately constructs and continuously updates a complete and traceable full lifecycle file covering the FTU from factory delivery, testing, commissioning, all maintenance operations, to its eventual scrapping. This provides a solid data foundation for subsequent data-driven equipment health status assessments and preventative maintenance.

[0251] The data processing method for the feeder terminal provided in this application has the following beneficial effects: (1) Achieving platform unification and wireless secure operation and maintenance, solving the risks of tool heterogeneity and high-altitude operations: This application's embodiment introduces a standardized object model to perform unified functional abstraction (including attributes, services, and events) on feeder terminals from different manufacturers, enabling the unified maintenance software platform to dynamically generate standardized user interfaces. Compared to related technologies where maintenance personnel need to master dozens of specialized software programs with different functions, this application achieves "one-machine maintenance," fundamentally solving the "software silo" problem caused by software heterogeneity, and significantly reducing the skill requirements and training costs for maintenance personnel. More importantly, this application establishes a Bluetooth wireless communication channel based on national cryptographic algorithm-encrypted chip bidirectional authentication, replacing the traditional wired connection method, achieving pole-free ground-based secure operation and maintenance, completely eliminating the risks of high-altitude operations caused by on-site wiring, and greatly enhancing operational safety.

[0252] (2) Automating and standardizing the debugging process to eliminate the inefficiency and unreliability of manual operation: This application's embodiment introduces a user-customizable operation and maintenance template, pre-arranging the complex on-site debugging process into a standardized script. On-site maintenance personnel only need to load this template to automatically execute the test instruction sequence and compare the results, achieving automatic joint debugging. Compared to related technologies that rely entirely on inefficient and error-prone manual input and visual comparison, this application transforms the debugging process from manual to automated, significantly improving on-site work efficiency and ensuring the standardization of debugging work and the consistency and traceability of results. Simultaneously, this automation solution decouples the dependence on traditional standard source equipment, further simplifying the equipment access and debugging process and accelerating project progress.

[0253] (3) Constructing a full lifecycle archive, connecting the data value chain, and supporting refined and intelligent operation and maintenance: This application embodiment solves the problem of fragmented operation and maintenance data that cannot form management value in related technologies by systematically integrating multi-source data in the background management system. Specifically, this method strongly associates the structured debugging record report generated by automated testing, the operation and maintenance log generated by manual operation, and external data such as factory test reports and power research institute test reports that can be imported with the unique identifier of the feeder terminal. In this way, this application constructs a complete and continuous full lifecycle archive covering the equipment from factory delivery, grid connection, commissioning to all operation and maintenance and even scrapping. This archive connects the previously broken data value chain, providing a solid data foundation for preventive maintenance, fault root cause tracing, and health status assessment of the equipment, thereby strongly supporting more advanced power intelligent operation and maintenance applications.

[0254] In summary, this application's embodiments construct an intelligent operation and maintenance framework for feeder terminals that integrates wireless secure communication, unified platform abstraction, process automation, and full data lifecycle integration. This not only fundamentally solves the core technical problems of heterogeneous tools, high-altitude operation risks, inefficient manual debugging, and fragmented data management inherent in traditional operation and maintenance models, but more importantly, it establishes a modern power distribution operation and maintenance paradigm based on model-driven and data-driven approaches. This paradigm replaces manufacturer-bound proprietary software with standardized physical models, replaces debugging processes reliant on manual experience with programmable automated templates, and transforms field operations based on isolated, real-time data into systematic management oriented towards full lifecycle archives. This significantly improves the efficiency of field operation and maintenance, personnel safety, and the standardization of debugging, and provides crucial technical support for achieving equipment fault prediction and health status assessment based on big data analysis, powerfully promoting the refinement and intelligentization of power distribution network operation and maintenance management.

[0255] The following description continues to illustrate the exemplary structure of the data processing device 555 for the feeder terminal provided in this application embodiment as a software module. In some embodiments, such as... Figure 2 As shown, the software module in the data processing device 555 of the feeder terminal stored in the memory 550 may include: The user interface generation module 5551 is used to parse the device model file of the feeder terminal using a preset object model to obtain the attribute list, service list and event list of the feeder terminal, and generate the user interface based on the attribute list, service list and event list. The debugging record generation module 5552 is used to load a preset operation and maintenance template through the user operation interface. The preset operation and maintenance template includes a test instruction sequence and a set of expected test results corresponding to the test instruction sequence; sends the test instruction sequence to the feeder terminal to execute the test, records the test process information, compares the actual test result set obtained after the test with the expected test result set, and generates a debugging record report based on the comparison results and test process information. The operation and maintenance log generation module 5553 is used to perform operation and maintenance operations on the feeder terminal through the user operation interface, and generate operation and maintenance logs based on the operation and maintenance operations and their response results. The life record generation module 5554 is used to integrate debugging record reports and operation and maintenance logs to obtain the full life record of the feeder terminal.

[0256] In some embodiments, the operation interface generation module 5551 is further configured to use a preset object model to parse the state variables and configuration variables in the device model file, wherein the state variables are used to characterize the current state of the feeder terminal and the configuration variables are used to characterize the operating parameters of the feeder terminal, and integrate the state variables and configuration variables into an attribute list; use the preset object model to parse the services that can be called in the device model file and generate a service list including all services; use the preset object model to parse the events that can be actively reported by the feeder terminal in the device model file and integrate all events into an event list.

[0257] In some embodiments, the user interface generation module 5551 is further configured to obtain a preset interface layout template, wherein the interface layout template includes a data monitoring area, a remote control area, and a real-time event sequence recording area; generate data display items in the data monitoring area of ​​the interface layout template based on the attribute list; generate operation controls in the remote control area of ​​the interface layout template based on the service list; and generate an event log display area in the real-time event sequence recording area of ​​the interface layout template based on the event list, thereby obtaining a user interface, wherein the event log display area is used to present events in the event list.

[0258] In some embodiments, the debug record generation module 5552 is further configured to obtain a test process information template; for each test instruction in the test instruction sequence, the following steps are performed: based on a wireless communication protocol, the current test instruction is encoded into a test instruction message; the test instruction message is encrypted using a preset session key, and the encrypted test instruction message is sent to the feeder terminal via wireless communication; the sent test instruction message and the timestamp corresponding to the test instruction message are synchronously recorded in the test process information template; the response message corresponding to the current test instruction returned by the feeder terminal is received, and the response message is parsed to obtain the actual test result corresponding to the current test instruction and the response result corresponding to the current test instruction; the response result and the timestamp corresponding to the response result are synchronously recorded in the test process information template to obtain the test process information.

[0259] In some embodiments, the debug record generation module 5552 is further configured to integrate the actual test results corresponding to each test instruction to obtain an actual test result set; compare the actual test result set with the expected test result set to obtain a comparison result; and integrate the test process information and the comparison result to generate a debug record report.

[0260] In some embodiments, the operation and maintenance log generation module 5553 is further configured to obtain the operation and maintenance operation instructions corresponding to the operation and maintenance operation, convert the operation and maintenance operation instructions into operation and maintenance operation messages based on the wireless communication protocol; encrypt the operation and maintenance operation messages using a preset session key, and send the encrypted operation and maintenance operation messages to the feeder terminal via wireless communication; receive the operation and maintenance response messages returned by the feeder terminal, parse the operation and maintenance response messages to obtain the response results of the operation and maintenance operation; and record the operation and maintenance operation and the response results of the operation and maintenance operation to obtain the operation and maintenance log.

[0261] In some embodiments, the life record generation module 5554 is also used to obtain the initial test report and identity identifier of the feeder terminal, and create a record file based on the identity identifier; store the initial performance data in the initial test report as baseline data in the record file; and store the debugging record report and operation and maintenance log in the record file in chronological order to obtain a full life record.

[0262] In some embodiments, the data processing device 555 of the feeder terminal further includes: a key generation module 5555, configured to send a first authentication request to the feeder terminal; receive a second authentication request and a response result of the first authentication request returned by the feeder terminal, wherein the second authentication request includes the identity identifier of the feeder terminal; when the response result of the first authentication request is correct and the identity identifier of the feeder terminal is valid, generate a preset session key, and establish an encrypted wireless communication connection with the feeder terminal using the preset session key.

[0263] This application provides a computer program product, which includes a computer program or computer-executable instructions stored in a computer-readable storage medium. The processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the data processing method for the feeder terminal described above in this application.

[0264] This application provides a computer-readable storage medium storing computer-executable instructions or a computer program. When the computer-executable instructions or the computer program are executed by a processor, the processor will execute the data processing method for the feeder terminal provided in this application. For example, ... Figure 3 The data processing method of the feeder terminal is shown.

[0265] In some embodiments, the computer-readable storage medium may be a memory such as RAM, ROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0266] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0267] As an example, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0268] As an example, computer-executable instructions can be deployed to execute on a single electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0269] In summary, this application's embodiments utilize a pre-defined object model to standardize the parsing of equipment model files for feeder terminals from different manufacturers. This not only solves the problem of equipment heterogeneity but also provides a foundation for automatically generating user interfaces with clearly defined functional partitions. Based on this interface, a pre-defined maintenance template is loaded, enabling the automatic execution of test command sequences and result comparison, transforming the manual debugging process into an efficient and standardized automated workflow. Furthermore, this application systematically integrates the debugging record reports generated by automated testing with the maintenance logs generated by manual maintenance, forming a full lifecycle archive bound to the unique identifier of the equipment. This archive not only provides precise evidence for fault tracing but also allows for in-depth utilization of its accumulated historical data: for example, by using analytical algorithms to mine high-frequency operation sequences to automatically generate more optimized recommended maintenance templates, or by driving artificial intelligence models to perform real-time data inference to achieve automatic fault diagnosis and parameter self-tuning. This series of data processing methods collectively constructs a complete closed loop from standardized operation and automated testing to data-driven management and intelligent analysis, significantly improving the efficiency, accuracy, and data value of the entire maintenance process.

[0270] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A data processing method for a feeder terminal, characterized in that, The method includes: The device model file of the feeder terminal is parsed using a preset object model to obtain the attribute list, service list and event list of the feeder terminal, and a user operation interface is generated based on the attribute list, service list and event list. The user interface loads a preset operation and maintenance template, which includes a test instruction sequence and a set of expected test results corresponding to the test instruction sequence. The test instruction sequence is sent to the feeder terminal to execute the test, and the test process information is recorded. The actual test result set obtained after the test is executed is compared with the expected test result set, and a debugging record report is generated based on the comparison result and the test process information. The user interface is used to perform maintenance operations on the feeder terminal, and maintenance logs are generated based on the maintenance operations and their response results. By integrating the debugging record report and the operation and maintenance log, a full lifecycle file of the feeder terminal is obtained.

2. The method according to claim 1, characterized in that, The process involves parsing the device model file of the feeder terminal using a preset object model to obtain the attribute list, service list, and event list of the feeder terminal, including: Using the preset object model, the state variables and configuration variables in the device model file are parsed out. The state variables are used to characterize the current state of the feeder terminal, and the configuration variables are used to characterize the operating parameters of the feeder terminal. The state variables and configuration variables are then integrated into the attribute list. Using the preset object model, the services that can be called in the device model file are parsed out, and a service list including all the services is generated; Using the preset object model, the events that can be actively reported by the feeder terminal in the device model file are parsed out, and all the events are integrated into the event list.

3. The method according to claim 1, characterized in that, The step of generating a user interface based on the attribute list, the service list, and the event list includes: Obtain a preset interface layout template, wherein the interface layout template includes a data monitoring area, a remote control area, and a real-time event sequence recording area; Based on the attribute list, data display items are generated in the data monitoring area of ​​the interface layout template; Based on the service list, operation controls are generated in the remote control area of ​​the interface layout template; Based on the event list, an event log display area is generated in the real-time event sequence recording area in the interface layout template to obtain the user operation interface, wherein the event log display area is used to present the events in the event list.

4. The method according to claim 1, characterized in that, The test instruction sequence includes at least one test instruction. Sending the test instruction sequence to the feeder terminal to execute the test and recording test process information includes: Get test process information template; For each test instruction in the test instruction sequence, the following steps are performed: Encode the current test instruction into a test instruction message based on a wireless communication protocol; encrypt the test instruction message using a preset session key, and send the encrypted test instruction message to the feeder terminal via wireless communication; synchronously record the sent test instruction message and its corresponding timestamp in the test process information template; receive the response message corresponding to the current test instruction returned by the feeder terminal, parse the response message to obtain the actual test result and the response result corresponding to the current test instruction, and synchronously record the response result and its corresponding timestamp in the test process information template to obtain the test process information.

5. The method according to claim 4, characterized in that, The process involves comparing the actual test result set obtained after performing the test with the expected test result set, and generating a debug record report based on the comparison results and the test process information, including: The actual test results corresponding to each of the aforementioned test instructions are integrated to obtain the set of actual test results; The actual test result set is compared with the expected test result set to obtain the comparison result; The test process information and the comparison results are integrated to generate the debug record report.

6. The method according to claim 1, characterized in that, The operation and maintenance of the feeder terminal is performed through the user interface. Based on the operation and maintenance operations and their response results, an operation and maintenance log is generated, including: Obtain the operation and maintenance instructions corresponding to the operation and maintenance operation, and convert the operation and maintenance instructions into operation and maintenance operation messages based on the wireless communication protocol; The operation and maintenance message is encrypted using a preset session key, and the encrypted operation and maintenance message is sent to the feeder terminal via wireless communication. The system receives the maintenance response message returned by the feeder terminal, parses the maintenance response message, and obtains the response result of the maintenance operation. The operation and maintenance operations and their response results are recorded to obtain the operation and maintenance log.

7. The method according to claim 1, characterized in that, The integration of the debugging record report and the operation and maintenance log yields the full lifecycle archive of the feeder terminal, including: Obtain the initial test report and identification of the feeder terminal, and create an archive file based on the identification; The initial performance data in the initial test report is used as baseline data and stored in the archive file; The debugging record report and the operation and maintenance log are stored in the archive file in chronological order to obtain the full life cycle archive.

8. The method according to any one of claims 1-7, characterized in that, Before parsing the device model file of the feeder terminal using a preset object model to obtain the attribute list, service list, and event list of the feeder terminal, the method further includes: Send a first authentication request to the feeder terminal; The system receives a second authentication request and a response result of the first authentication request returned by the feeder terminal, wherein the second authentication request includes the identity identifier of the feeder terminal; When the response to the first authentication request is correct and the identity of the feeder terminal is valid, a preset session key is generated, and an encrypted wireless communication connection with the feeder terminal is established using the preset session key.

9. A data processing device for a feeder terminal, characterized in that, The device includes: The user interface generation module is used to parse the device model file of the feeder terminal using a preset object model to obtain the attribute list, service list and event list of the feeder terminal, and generate a user interface based on the attribute list, service list and event list. The debugging record generation module is used to load a preset operation and maintenance template through the user operation interface. The preset operation and maintenance template includes a test instruction sequence and a set of expected test results corresponding to the test instruction sequence. The module sends the test instruction sequence to the feeder terminal to execute the test and records the test process information. It compares the actual test result set obtained after the test with the expected test result set and generates a debugging record report based on the comparison result and the test process information. The operation and maintenance log generation module is used to perform operation and maintenance operations on the feeder terminal through the user operation interface, and generate operation and maintenance logs based on the operation and maintenance operations and the response results of the operation and maintenance operations. The life record generation module is used to integrate the debugging record report and the operation and maintenance log to obtain the full life record of the feeder terminal.

10. An electronic device, characterized in that, The electronic device includes: Memory is used to store executable instructions or computer programs. A processor, when executing computer-executable instructions or computer programs stored in the memory, implements the method according to any one of claims 1 to 8.

11. A computer-readable storage medium storing computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, they implement the method described in any one of claims 1 to 8.

12. A computer program product comprising computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, they implement the method according to any one of claims 1 to 8.

Images