Scheduling access configuration method and system for plant station equipment

Abstract

The invention discloses an automatic configuration method for dispatching access of plant station equipment, and the method comprises the steps: A, obtaining communication data from the plant station equipment, and enabling the communication data to comprise a frame structure field; b, based on the frame structure field, identifying a communication protocol type by comparing an initial identifier, a function code field and a frame length field; c, in combination with the communication protocol type and the equipment attribute field, an access configuration strategy template is matched, and the template comprises a communication parameter set, an interface adaptation rule and a signal mapping relation; d, generating a structured configuration data file according to the configuration strategy template; and E, deploying the configuration data file to a scheduling system to complete equipment communication registration and data interaction initialization.

Description

Technical Field

[0001] The present invention relates to the technical field of power automation, and particularly to a scheduling access configuration method and system for substation equipment. Background Art

[0002] With the development of the new power system and the ubiquitous power Internet of Things, the number of substation equipment in the power grid is increasing continuously, and the types of access equipment show a trend of diversification and protocol complexity. When the traditional scheduling system accesses new equipment, it usually requires manual analysis of the equipment protocol type, manual configuration of point tables and link parameters, and system deployment and debugging. The process is cumbersome, inefficient, and prone to configuration deviations, affecting communication stability and operation and maintenance efficiency.

[0003] In the prior art, the access process of substation equipment usually includes: on-site manual collection of equipment protocol information, generation of a configuration file through a dedicated template tool, and then uploading it to the scheduling system for registration. However, due to problems such as inconsistent communication protocols, incomplete field information, and high on-site configuration error rates for the access equipment, especially in the case of coexistence of multiple protocols such as IEC 104, IEC 61850, MODBUS, and DNP3, the manual configuration method is difficult to meet the requirements of flexibility and large-scale access. In addition, the current systems generally lack the ability of automatic policy judgment and fault tolerance for the access process. For example, when the master station load is too high, forcing the deployment of new equipment may lead to a decline in system performance or even abnormal interruption.

[0004] In terms of exception management, some scheduling systems only provide single-point threshold judgment of operating parameters and do not form a mechanism for multi-parameter linkage and trend analysis, resulting in insufficient accuracy of exception identification and serious false alarms and missed alarms. At the same time, most current systems lack version control and automatic rollback capabilities for access configuration. Once the deployment fails or the configuration is incorrect, it is impossible to quickly restore to the original state, increasing the cost of manual intervention and operation risks.

[0005] Therefore, there is an urgent need for a scheduling access configuration method and system for substation equipment to improve the access efficiency of substation equipment, deployment security, and system operation stability. Summary of the Invention

[0006] The present invention aims to at least solve one of the technical problems such as low communication configuration efficiency, high deployment risk, and weak ability to identify operation exceptions existing in the existing scheduling system. For this purpose, an object of the present invention is to propose an automatic configuration system for scheduling access of substation equipment, including: A. Obtaining communication data from substation equipment, where the communication data includes frame structure fields; B. Based on the frame structure fields, identifying the communication protocol type by comparing the start identifier, function code field, and frame length field; C. Combine the communication protocol type and the device attribute field to match the access configuration policy template, which includes a set of communication parameters, interface adaptation rules, and signal mapping relationships; D. Generate a structured configuration data file according to the configuration policy template; E. Deploy the configuration data file to the scheduling system to complete device communication registration and data interaction initialization.

[0007] An object of the present invention is to propose a scheduling platform system for automatic access configuration of substation equipment, including: A communication protocol recognition module for extracting communication data fields and identifying the communication protocol type; A configuration policy generation module for generating an access configuration policy according to the communication protocol type and device attributes; A configuration data generation module for generating a structured configuration data file based on the configuration policy; A configuration deployment module for deploying the configuration data file to the scheduling master station system.

[0008] In some examples of the present invention, the communication protocol type recognition includes: Extract the start identifier, frame length field, and function code field in the communication data; Compare the extracted fields with a preset protocol feature library to determine the adopted communication protocol type.

[0009] In some examples of the present invention, when the device attribute field is missing, the platform executes a field scoring mechanism and triggers a field completion logic to generate a complete configuration policy.

[0010] In some examples of the present invention, the field scoring mechanism includes: Set weight factors for multiple device fields; Calculate the total score value based on the matching situation between the uploaded fields and the template fields; Compare the total score value with a set threshold; If the score value is lower than the threshold, call the default field template to complete the missing fields.

[0011] In some examples of the present invention, the structured configuration data file includes a communication point table, a link parameter set, and a signal mapping table, and is output in JSON format, SCD format, or extended configuration language format.

[0012] In some examples of the present invention, the configuration deployment module supports: Local deployment method; Network interface remote push deployment method; Multi-site batch deployment method; And it supports automatically adapting to various interface protocol types of scheduling systems.

[0013] In some examples of the present invention, before deployment, the platform collects parameters such as the length of the main station task queue, the running load ratio, and the network latency, and based on the deployment policy decision model, determines the deployment mode as immediate deployment, delayed deployment, or batch deployment.

[0014] In some examples of the present invention, after device access, the platform performs trend analysis on the operating parameters based on a sliding time window; when at least two key parameters exceed the set threshold in multiple consecutive sampling periods and there is no reverse falling trend, an anomaly recognition mechanism is triggered.

[0015] In some examples of the present invention, when the platform detects deployment failure, communication anomaly, or operation anomaly, it automatically triggers the configuration version control mechanism, rolls back the deployment configuration to the previous valid version, and records the anomaly time point and the configuration change log.

[0016] The additional aspects and advantages of the present invention will be partially given in the following description, partially become obvious from the following description, or be understood through the practice of the present invention. It has the following beneficial effects: Therefore, the present invention realizes automatic protocol type identification through communication data field comparison, improving the accuracy and efficiency of protocol determination; By combining device attribute information to match the configuration policy template, it realizes the automatic construction of communication parameters and interface adaptation structures, improving the standardization level of configuration generation; By outputting the configuration data file in a structured manner, it enhances the adaptability and parsability of the configuration file between different platforms; By deploying the configuration data to the scheduling system to complete communication initialization, it effectively reduces the probability of manual deployment failure; Each step of the present invention constitutes a complete closed-loop configuration process, with clear input and output logic, and has good engineering integration value and promotion adaptability. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the following drawings are some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0018] Figure 1 It is a schematic diagram of the overall structure of the scheduling platform system of the present invention; Figure 2It is a schematic diagram of the steps in the implementation process of the method of the present invention; Figure 3 It is an internal functional structure block diagram of the configuration and deployment module; Figure 4 It is a flow chart for identifying and warning of deployment exception trends. Specific implementation manners

[0019] To make the objectives, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0020] In the description of the present invention, it should be understood that the terms "center", "longitudinal", "transverse", "length", "width", "thickness", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", "clockwise", "counterclockwise", "axial", "radial", "circumferential", etc. indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and thus cannot be construed as a limitation of the present invention. In addition, the features defined with "first", "second" may explicitly or implicitly include one or more of such features. In the description of the present invention, unless otherwise specified, the meaning of "plurality" is two or more. In the description of the present invention, it should be noted that, unless otherwise clearly defined and limited, the terms "installed", "connected", "connected" should be understood in a broad sense. For example, it may be a fixed connection, a detachable connection, or an integral connection; it may be a mechanical connection or an electrical connection; it may be directly connected, or indirectly connected through an intermediate medium, and it may be the internal communication of two elements. For those of ordinary skill in the art, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0021] The embodiments of the present invention will be described in detail below. The examples of the embodiments are shown in the accompanying drawings, where the same or similar reference numerals represent the same or similar elements or elements with the same or similar functions from beginning to end. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention and should not be construed as a limitation of the present invention.

[0022] Figure 1 It is a general structure schematic diagram of the scheduling platform system of the present invention;Figure 2 It is a schematic diagram of the steps of the implementation process of the method of the present invention; Figure 3 It is an internal functional structure block diagram of the configuration and deployment module; Figure 4 It is a flowchart for identifying and alarming deployment anomaly trends.

[0023] Please refer to Figures 1 - 3 , the method of this embodiment runs in the dispatching platform system and is applicable to the power dispatching automation system with communication access management capabilities. This method includes: A. Obtain communication data from substation equipment, where the communication data includes frame structure fields; B. Based on the frame structure fields, identify the communication protocol type by comparing the start identifier, function code field, and frame length field; C. Combine the communication protocol type with the device attribute fields to match the access configuration policy template, and the template includes a communication parameter set, interface adaptation rules, and signal mapping relationships; D. Generate a structured configuration data file according to the configuration policy template; E. Deploy the configuration data file to the dispatching system to complete device communication registration and data interaction initialization.

[0024] Specifically, in the stage when the device is initially connected to the system, the platform first receives the initialization communication data from the substation equipment through the communication link establishment process. This communication data is sent by the device according to its inherent communication protocol format, usually organized in a frame structure, and its content includes a start identifier, a frame length field, a function code field, and other control information. The platform performs a preliminary analysis on the received data and extracts the key frame structure fields to provide a basis for subsequent protocol type identification.

[0025] Subsequently, the platform uses the built-in communication protocol identification module to compare the rules of the extracted frame structure fields. The platform is pre-configured with frame structure feature libraries of multiple communication protocols, including the frame structure feature descriptions of common communication protocols such as IEC 104, MODBUS RTU, IEC61850, and DNP3. By comparing the start identifier format, function code value range, and frame length structure, the platform can accurately identify the communication protocol type adopted by the current substation equipment. The identification process does not rely on the device to actively report the protocol identifier, but realizes the automatic identification of the protocol type through the matching of field structure features.

[0026] After determining the type of communication protocol, the platform further combines the attribute field information provided by the substation equipment, including equipment type, manufacturer identifier, interface type, etc., to construct an access parameter set for the equipment. This parameter set is input into the configuration policy template library as a policy matching condition. The template library in the platform pre-stores multiple standardized configuration templates based on different combinations of communication protocols and equipment types. Each template contains a complete set of communication parameters, interface adaptation rules, and signal mapping relationships. The platform retrieves the configuration policy template with the highest matching degree based on the equipment parameter set and loads the template content to prepare for generating configuration data.

[0027] After the platform finishes loading the matching configuration policy template, it starts to generate a structured configuration data file. The structured configuration data file is an important intermediary for completing communication initialization between the dispatching platform and the master station system, with a unified data field structure, logical organization level, and format standard. The platform organizes modular paragraphs such as communication parameter blocks, interface information blocks, point table mapping blocks, and format declaration blocks according to the content of the configuration template to construct a complete data object. This configuration data file can be output in standard formats such as JSON, SCD, XML, etc. to adapt to the communication parameter import mechanism and interface access requirements of the master station system.

[0028] After completing the generation of the configuration data file, the platform transmits this file to the target dispatching master station system through the configuration deployment module. Depending on the different system deployment architectures, the deployment method can be one of the modes such as local file mounting, remote interface pushing, and scheduled batch loading. After receiving the configuration data, the master station system automatically parses the file content and completes a series of operations such as device registration, point table loading, communication link establishment, and protocol session initialization. After successful communication initialization, the device is officially connected to the dispatching system and has the ability to upload real-time data and respond to dispatching control instructions.

[0029] The entire method process starts from the collection of communication data, runs through protocol identification, template selection, data construction, and finally deployment execution. The steps are clear, the boundaries are distinct, and the processing chain has a rigorous logic. Each technical module used in each stage can be implemented by independent components, with good platform scalability and reusability. The abstract expression of the configuration policy template enables the method to implement a unified processing logic when facing equipment from different manufacturers, different types, and different protocols. The standardized output of the structured configuration data enables the system to quickly access heterogeneous devices with minimal manual intervention.

[0030] The method provided by the present invention not only solves the problems of cumbersome manual configuration, high misconfiguration rate, and unstable adaptation during the access process of substation equipment, but also constructs an automated, modular, and structurally extensible dispatching access technology system, which is particularly suitable for typical power dispatching scenarios such as multi-type devices, high-concurrency access, and protocol complexity, and has significant engineering application value and industrial promotion prospects.

[0031] Please refer to Figure 1 , the present invention provides a dispatching platform system for automatic access configuration of substation equipment. This system is used to automatically identify the device communication protocol, match the access strategy, generate configuration data and deploy it to the dispatching master station, realizing the whole process of communication initialization. The system has a modular structure, can adapt to substation equipment with multiple protocols, multiple manufacturers and multiple platforms, improve the access efficiency and configuration consistency of the dispatching system, and is widely applicable to scenarios such as new power systems, integrated energy control platforms, and automated industrial data dispatching systems.

[0032] The system includes a communication protocol identification module, a configuration strategy generation module, a configuration data generation module, and a configuration deployment module. The modules of the system work together in a task-driven manner to form a complete communication configuration processing chain. The communication protocol identification module is used to extract communication data fields and identify the communication protocol type; the configuration strategy generation module is used to generate access configuration strategies according to the communication protocol type and device attributes; the configuration data generation module is used to generate a structured configuration data file based on the configuration strategy; the configuration deployment module is used to deploy the configuration data file to the dispatching master station system.

[0033] During the operation of the system, the communication protocol identification module first receives the communication initialization data uploaded by the substation equipment through the communication link. This data is usually organized in the form of a protocol data frame, and its structure contains key communication field information such as the start identifier, function code field, and frame length field. This module parses the structure of the received data and extracts the field set for protocol judgment. The system pre-sets the structure feature rules of multiple communication protocols (such as IEC 104, MODBUS, DNP3, IEC61850, etc.), and realizes the automatic identification of the protocol type through the structure matching with the extracted fields. The identification process does not require manual annotation or device active reporting, and can support protocol inference in the case where the protocol is not explicitly marked.

[0034] After the protocol identification is completed, the platform combines the communication protocol type with other attribute fields of the substation equipment, such as device model, manufacturer identification, communication port type, etc., and passes them as input conditions to the configuration strategy generation module. This module is responsible for retrieving the access configuration strategy that matches the current device from the strategy template library. Each configuration strategy template describes a standardized access parameter set for a specific device and communication protocol combination, including a communication parameter set (such as baud rate, data bits, parity method, etc.), interface adaptation rules (including the main station access interface type, protocol layer parameter matching method), and signal mapping relationship (used to define the logical naming and address binding relationship of measurement point fields). The strategy generation module selects the optimal configuration plan based on the template matching degree score, providing template support for the subsequent construction of configuration data.

[0035] After the configuration policy is matched, the configuration data generation module starts the structured configuration data construction process. Based on the parameters in the selected policy template, this module generates a configuration data file with standard format, complete fields, and clear semantics. The structured data file generally includes multiple structural areas such as a communication link parameter section, a measurement point definition section, an address mapping section, an interface information section, and a file version control section. The platform supports outputting the configuration data in standard industrial formats such as JSON, XML, SCD, etc., to adapt to the parsing capabilities of different dispatching master station systems. During the file generation process, structural integrity checks, semantic consistency verification, and field legality verification are performed synchronously to ensure the quality of data delivery.

[0036] After the configuration file is generated, the system transfers the data to the configuration deployment module, which completes the deployment task. Depending on the type and deployment method of the master station system, this module supports multiple deployment means such as local writing, shared directory pushing, interface uploading, and network service docking. For master stations that require remote configuration, this module realizes the automatic pushing of the configuration file through the HTTPS API, MQTT interface, or FTP channel; for integrated deployment master stations, hot loading can be achieved by mounting a shared path through middleware. The deployment module simultaneously monitors the deployment progress, feedbacks the deployment status, and generates a deployment log for the platform to record and trace exceptions.

[0037] After the deployment is completed, the dispatching master station system parses the received configuration file and automatically completes the registration of new devices, the loading of communication link configurations, the attachment of measurement point data, and the establishment of protocol connections. After the device goes online, it has functions such as real-time data uploading, telemetry and telecontrol reception, and remote control execution, thus realizing the effective communication access between the device and the dispatching system.

[0038] This dispatching platform system is implemented using a microservices architecture or a pluggable module architecture in engineering. Each module has independent logical processing capabilities and data input / output interfaces, and supports on-demand deployment and centralized scheduling. The system can not only run as an independent deployment platform but also be integrated with existing dispatching systems, communication front-end systems, SCADA platforms, etc., with good compatibility and scalability.

[0039] This system is applicable to typical scenarios such as the centralized access of newly installed devices, the large-scale online of substations or distribution terminals, and the self-configuration access of remote edge devices. It can effectively reduce the operation and maintenance costs, reduce the manual configuration workload, improve the system access stability and operation efficiency, and has high technical practicality and industrial promotion value.

[0040] Please refer to Figure 1, in the scheduling platform system implemented in the present invention, the communication protocol recognition module further includes a field extraction unit and a field comparison and recognition unit, which together constitute the core structure for recognizing the communication protocol types of substation equipment. Through the design of this module, the system can automatically complete the judgment of the communication protocol at the first time when receiving device communication data, providing key support for the subsequent configuration strategy matching and configuration data generation processes.

[0041] The field extraction unit is used to extract the start identifier, function code field, and frame length field from the communication data frame. These three fields are the most representative characteristic fields in the communication protocol frame structure. As a preprocessing module, this unit first performs frame header recognition after the communication data frame arrives, locates the start identifier, and then parses the function code and frame length fields according to the offset rules in the protocol candidate list. The field extraction process adopts a combination of position index matching, byte stream segmentation, and field verification mechanisms to ensure the accuracy and structural consistency of the extracted fields. To support the situation where the field lengths and positions may vary in different protocols, the system presets multiple frame structure templates and integrates template-driven extraction strategies in the field extraction unit to achieve dynamic field parsing.

[0042] After the field extraction is completed, the field comparison and recognition unit starts the comparison process. This unit is used to compare based on the extracted field information with the preset protocol feature library to identify the communication protocol type. The protocol feature library stores the standard field combination features of common industrial communication protocols, including different start byte formats, function code number ranges, whether the frame structure is fixed-length or variable-length, etc. The field comparison and recognition unit takes the three field information output by the field extraction unit as input and performs one-by-one structural matching with the protocol templates in the feature library. The comparison methods include field value comparison, logical structure reconstruction, and field combination feature verification. If multiple protocols have similar matching degrees during the comparison process, the system adopts a confidence scoring mechanism to comprehensively judge the most likely protocol type according to the matching weight and field compliance, and outputs the result.

[0043] The design of this module enables the scheduling platform system to no longer rely on the device to report the communication protocol itself, nor does it require manual configuration of protocol information, thus improving the access intelligence level of the entire system. Especially in the face of unclear protocols, diverse versions, and complex on-site environments, the field comparison and recognition mechanism can operate stably, improving the accuracy and robustness of protocol judgment. In addition, this module also supports dynamic updating of the protocol feature library, allowing system maintenance personnel to supplement new entries according to the new protocol structure on-site, realizing the ability to adapt to continuously evolving protocols.

[0044] In terms of system integration, the field extraction unit is directly connected to the field comparison and recognition unit through a data interface. The two cooperate to complete the whole process of the communication protocol recognition function, that is: obtaining key structure fields from the original communication data, and then determining the protocol type through structural feature comparison. Due to its clear structure and dedicated function, this module can be independently deployed on the main control node of the dispatching platform system, or integrated into scenarios such as distributed communication front-end systems and edge gateway devices to run, with good deployment flexibility and module reuse ability.

[0045] Generally speaking, the communication protocol recognition module described in the embodiment of the present invention is composed of a field extraction unit for extracting the start identifier, function code field and frame length field in the communication data frame, and a field comparison and recognition unit for comparing the extracted field information with a preset protocol feature library to identify the communication protocol type. It can realize the automatic judgment of the protocol type and the pre-position decision of the configuration path in the scenario of multi-protocol complex device access, significantly reduce the manual configuration error, improve the access deployment success rate, and meet the needs of the current and future diversified development of power dispatching system devices.

[0046] Please refer to Figure 1 , in an embodiment of the dispatching platform system of the present invention, the configuration strategy generation module is further refined into two functional components: a scoring unit and a template screening unit, which are respectively used to score the matching degree between the communication protocol type and the device attribute fields, and select the strategy template with the highest score from multiple candidate configuration strategy templates. The design purpose is to realize the intelligence and refinement of the configuration strategy selection, improve the adaptation accuracy of the strategy template and the target device, so as to improve the accuracy of the configuration file generation and the success rate of communication access.

[0047] After the communication protocol type of the substation equipment is recognized, the platform passes the communication protocol type and the device basic attribute fields into the configuration strategy generation module together. The scoring unit first performs multi-dimensional analysis on this set of input parameters. The platform presets a set of scoring rule systems to score the matching degree between each candidate configuration strategy template and the device. The key scoring factors involved at least include the following aspects: First, whether the communication protocol type is exactly the same as the protocol defined by the template; Second, whether the device model matches the defined range of the template; Third, whether the device manufacturer identifier is exactly the same; Fourth, the compatibility between the communication interface type used by the device and the preset interface of the template; Fifth, whether the geographical area or the main station number to which the device belongs conforms to the template configuration range.

[0048] Each factor is assigned a weight coefficient, and the weight can be flexibly adjusted according to project experience, configuration stability or manual setting strategy. The system adopts a weighted linear calculation method to merge the results of all scoring factors into a comprehensive scoring value. The scoring formula is as follows: , where is the score of the i-th scoring factor (for example: 0 to 100), is the comprehensive matching score of the template and the current device.

[0049] After all candidate templates are scored, the scoring unit will generate a structured result data table containing template IDs, scoring details, final scores, etc., and hand it over to the template screening unit for processing. The template screening unit performs template optimization operations from the scoring list, and the default logic is to select the one with the highest score. If there are multiple templates with the same score or within the error tolerance range, the platform will enable the preset priority rules for secondary judgment. The priority judgment rules usually make decisions in the order of "protocol consistency priority > manufacturer consistency priority > interface type compatibility priority", and finally output the unique target policy template number.

[0050] The output result of the template screening unit also includes the identification code of the policy template, score annotation description, and confidence level, which are used to support the call of the subsequent configuration data generation module, and are also convenient for the platform policy management module to perform analysis and feedback learning later. Both the scoring and screening logics are implemented in a modular encapsulation manner, supporting independent testing, policy fine-tuning, and rule updates, while ensuring the running performance and maintaining the controllability and transparency of the algorithm.

[0051] The present invention introduces a scoring unit for scoring the matching degree between the communication protocol type and the device attribute fields through the configuration policy generation module, and a template screening unit for selecting the policy with the highest score from multiple candidate configuration policy templates, so that the system can still accurately locate the configuration template based on objective scoring and priority policies in the face of situations such as incomplete device fields, fuzzy model information, or complex deployment scenarios. This scoring + screening structure not only improves the configuration intelligence level of the platform, but also enhances the compatibility of the system with the accessed devices and the configuration fault tolerance ability.

[0052] The scoring mechanism and screening strategy in this implementation method are applicable to all platform architectures that support automatic identification of communication protocols and structured input of attribute fields. Whether it is a centralized master station deployment environment or an edge intelligent access scenario, it can run stably. This technical design is especially applicable to intelligent scheduling platforms that need to quickly complete batch automatic access in large-scale, multi-device, and heterogeneous environments, which helps to improve the engineering efficiency and communication access quality of the dispatching automation system.

[0053] Please refer to Figure 1 , in the dispatching platform system described in the present invention, the configuration policy generation module further includes a field completion unit. The function of this unit is: in the case of missing device attribute fields, it automatically triggers the field completion logic to complete the missing fields so that the subsequent scoring process can continue without interruption.

[0054] When the device is connected to the platform, the system first extracts its communication protocol type and attribute field information. The fields include device model, manufacturer code, communication interface type, deployment area, etc. If any of the keyword fields is empty or not uploaded, the field completion unit immediately performs a field integrity check. This check is completed based on the list marked as "required fields" in the field definition table.

[0055] Once a field is detected as missing, the field completion unit will initiate the completion logic. The completion logic follows the following three methods: First, use the device number or ID to match the template binding records registered in the platform. If there are any, directly reference the fields in the binding template for filling; Second, perform a logical judgment on the existing fields through inference rules. For example, if the communication interface is RS485 and the protocol type is MODBUS, the system can automatically supplement default communication parameters such as "baud rate = 9600" and "data bits = 8"; Third, when the missing field is an optional field or a field marked as "allow default" in the platform configuration, the system fills in the default value according to the rules. All default values are sourced from the platform parameter library and have a unique configuration number and change record.

[0056] All completed fields will be marked with the status "auto_filled", and the scoring item for this field in the scoring unit will be set to "low confidence" processing, that is, reducing the maximum score weight coefficient of the corresponding scoring item, for example, from 1.0 to 0.6.

[0057] The device information structure after field completion will be passed into the scoring unit as a complete structure, and the scoring logic does not require additional adjustment, ensuring that the scoring mechanism has the same process after field completion. The data interface between the field completion unit and the scoring unit is a structured JSON object, and the field labels, data types, and units strictly conform to the platform data model definition to avoid any ambiguity.

[0058] In addition, the field completion unit supports logging and debugging switches. Each completion action will record: device number, missing field item, completion method, completion value, and the rule number used. The platform can review the completion process through the background interface and perform correction operations or turn off certain completion rules when necessary.

[0059] This field completion mechanism ensures that even if the device does not provide complete fields, the system can still run the scoring logic and configuration policy selection process, avoiding process interruption or manual intervention. Its logic is clear, the completion path is limited, the processing behavior is recordable, auditable, and traceable, and it has an engineering implementation foundation. It is only triggered by missing fields and does not affect the original configuration process during normal field input, ensuring module decoupling and stable behavior.

[0060] In this embodiment, the field completion unit, as a component of the configuration policy generation module, is used to trigger the completion logic when device attribute fields are missing, complete the fields, and ensure the continuous operation of the scoring logic and the template screening module, so as to complete the uninterrupted configuration policy generation link.

[0061] Please refer to Figure 1 , in an embodiment of the present invention, the configuration data generation module includes a structure construction unit for organizing communication parameter structures, link configuration structures, and measurement point configuration structures, and a data output unit for outputting a structured configuration data file according to a preset template format. This module is responsible for converting the policy template information output by the configuration policy generation module into standardized configuration data recognizable and deployable by the master station system, constituting the core generation link in the entire automated access process. The system's requirements for the generation of configuration data include correct field content, clear structural hierarchy, strong format compatibility, and traceable output, ensuring that the data file can be successfully parsed by the master station and used for communication initialization.

[0062] In the operation process, the platform first calls the structure construction unit to classify and organize the configuration parameters defined in the policy template. The communication parameter structure covers basic link parameters such as baud rate, data bits, parity mode, stop bits, and flow control mode; the link configuration structure includes link number, communication direction, logical address, master station interface number, and channel mapping relationship, etc.; the measurement point configuration structure defines the identification, data type, address number, unit, upload period, limit rule, etc. of telemetry, telemetry, and remote control measurement points. All fields are organized in a hierarchical manner of module - field group - field item and bound to the platform standard field model to ensure the consistency of field semantics and data structure.

[0063] The structure construction unit sequentially executes steps such as field parsing, default value filling, field legality verification, and field redundancy elimination during the construction process. After each structure is completed, a structure integrity flag bit is generated to ensure that there are no problems of missing fields or incorrect structural levels in the data object during the output stage. All fields are bound with data types, unit descriptions, and field identification codes, meeting the standardized requirements of the master station system for format semantics parsing.

[0064] After completing the organization of the field structure, the data model object is passed to the data output unit. The data output unit selects the corresponding format template for output according to the interface requirements of the current target master station system. Common formats include JSON (lightweight master station), XML (gateway - oriented system), SCD (based on IEC 61850 standard structure), etc. The platform has a built - in field - label mapping rule library and output template dictionary to ensure that the structured data fields can accurately correspond to the master station - side field structure during the file output process.

[0065] During the output operation performed by the data output unit, the system will complete the following tasks: (1) Field serialization processing to ensure that the field nesting structure and field order comply with the target format parsing rules; (2) Tag replacement processing to convert platform tags into standard tags or the tags expected by the master station; (3) Format verification mechanism to perform syntax checking on the file and check the integrity of field filling; (4) Meta information attachment to attach additional information such as generation time, platform version, configuration number, and generated user ID to the output data file, facilitating deployment tracking and version control.

[0066] The finally output configuration file will be used as the input source file for the deployment module and passed to the deployment control system. The content of this file covers complete communication link parameters, interface adaptation structures, and point table configuration information. The file structure is legal and the fields are clear, meeting the requirements for parsing and execution by the master station system. The master station can directly parse the configuration file to complete initialization operations such as device registration, protocol link establishment, and data point table loading.

[0067] The structure construction unit and the data output unit interact through a unified data interface. The structure construction unit is responsible for data organization, and the output unit is responsible for format adaptation and output implementation. Their responsibilities are clear and the module boundaries are well-defined. The configuration data generation module can be deployed within the platform master control system or run as an independent service in a microservices architecture, and is called through the task scheduling mechanism in the platform configuration process. The module supports logging and output traceback. The output file has a unique number and a structure summary, which are used for result verification and subsequent problem troubleshooting.

[0068] In summary, through the structure construction unit and the data output unit included in the configuration data generation module in this embodiment, the entire process from template parameters to a structured configuration file is completed. The structure construction unit is used to organize the communication parameter structure, link configuration structure, and measurement point configuration structure to ensure clear field classification and reasonable organizational structure; the data output unit is used to output a structured configuration data file according to a preset template format, and the generated result can be directly used for parsing by the master station system. The entire process design is clear, the behavior is controllable, and the logic is closed-loop, suitable for various platform deployment and master station docking scenarios, ensuring that the automatic configuration system has high implementability and adaptation stability in an engineering environment.

[0069] Please refer to Figure 1 、 3 In the scheduling platform system of the present invention, the configuration deployment module includes a master station identification unit for determining the target master station type according to the deployment method, and a deployment execution unit for transmitting the configuration data file to the target master station. The two cooperate to complete the adaptation transmission of the configuration file and the task of triggering communication initialization, ensuring that the configuration result can be accurately received and executed in actual engineering deployment, and realizing the effective conversion of the substation equipment from the "configuration generation" state to the "communication available" state.

[0070] The master station identification unit is responsible for determining the type of the target master station system based on the current deployment task parameters. The deployment methods can be divided into three scenarios: local deployment, network deployment, and hybrid deployment. The platform resolves the master station type according to the task context (such as task source, master station code, interface address format). For example: If the task is marked as "local master station deployment", the system will identify it as a local integrated SCADA master station; if the deployment task contains an HTTPS interface, an IP network segment, and an interface key, it will be identified as a remote Web API type master station; if the master station is deployed in a multi-level architecture (such as the power grid dispatching - city sub-control - plant station hierarchical structure), it will be identified as a hierarchical deployment type master station. The identification result is stored in the deployment task structure in the form of a master station type code + interface protocol identifier for subsequent module calls.

[0071] The master station identification unit has a built-in master station information mapping table, which covers the types of master station systems that the platform can access, the interface requirements of master station manufacturers, the adaptation description of the configuration file structure, and the deployment method rules. The master station types include but are not limited to: locally mountable master stations (supporting file system writing), remote interface type master stations (supporting HTTP / HTTPS REST calls), SCD loading type master stations (supporting IEC 61850 standard SCD import), third-party encrypted master stations (receiving files through key and certificate verification), etc. The master station identification unit completes a master station type judgment before the task execution, and the identification result is locked and unchanged after it is stable, ensuring that the configuration data transmission path is single, clear, and stable.

[0072] The deployment execution unit is responsible for transmitting the structured configuration data file to the target master station system according to the identification result of the master station identification unit. The transmission method corresponds one-to-one with the master station type, including: (1) Local replication method: directly write the configuration file to the specified path of the master station file system and set the configuration effective flag; (2) Network interface push method: use the interface protocol defined by the master station (such as RESTful API, MQTT message interface, FTP / SFTP transmission channel) to push data packets, accompanied by identity authentication parameters and interface keys; (3) Task queue writing method: encapsulate the configuration data into a deployment task object and write it to the message queue, which is pulled and processed by the master station receiving end component.

[0073] Before the deployment execution unit executes, it performs file integrity verification, format recognition, and field integrity detection on the configuration file to ensure that the file is legal. After the file transmission is successful, the platform records the deployment status and synchronizes the deployment response from the master station interface to determine whether the deployment is successful, whether it is automatically loaded, and whether manual confirmation is required. All deployment actions generate deployment logs, the content of which includes file name, target master station, transmission channel, response status, deployment duration, etc.

[0074] To improve deployment stability and issue traceability, the deployment execution unit also has an exception capture and retry mechanism. In cases such as interface call failure, file write failure, or no response from the master station, the platform will execute a preset retry policy, attempting up to 3 times; if it still fails, a deployment exception alert will be generated and it will enter the manual processing channel. The exception information is bound to the task parameters and pushed to the platform configuration console for engineering personnel to verify.

[0075] In actual deployment projects, the master station identification unit and the deployment execution unit usually cooperate and run in a modular service manner. The system supports operation modes such as asynchronous deployment, batch deployment, and scheduled deployment, and provides users with a "master station mapping configuration center" for managing the maintenance of master station interface parameters, deployment methods, and identification rules, improving the flexible adaptation ability of the platform. In module design, the communication protocols of the two units are unified and the structural boundaries are clear, and they can be deployed as independent microservice modules in the deployment link on the cloud platform or the scheduling edge node, with good module isolation and fault tolerance.

[0076] In summary, in this embodiment, the configuration deployment module includes a master station identification unit for determining the target master station type according to the deployment method, and a deployment execution unit for transmitting the configuration data file to the target master station. The master station identification unit ensures the adaptability and controllability of the deployment behavior, and the deployment execution unit completes the legal transmission and deployment confirmation of the data file. The two constitute the key output stage of "generation-delivery-effective" in the automatic configuration system closed-loop link.

[0077] Please refer to Figure 3 , in an embodiment of the scheduling platform system of the present invention, the deployment execution unit in the configuration deployment module includes a deployment policy judgment unit for judging the type of the target master station deployment policy, and a transmission control unit for performing corresponding transmission operations based on the deployment policy type. The two units cooperate to complete the adaptive deployment decision-making and actual transmission operations of the configuration data file, and are used to support the platform to achieve configurable, switchable, and controllable deployment behaviors in the face of various master station architectures and deployment policies.

[0078] During the system scheduling and deployment process, there are significant differences in the deployment methods of configuration data for different master stations. For example: some master stations use the file delivery method for deployment and need to write the configuration file to a specified directory; some master stations use the interface transmission method for deployment and require uploading configuration data through the HTTPS interface; there are also some master stations that need to perform manual approval and then manually load the configuration file. Therefore, to achieve automatic decision-making of the deployment behavior, the deployment policy judgment unit is responsible for judging the type of the deployment policy used by the target master station according to the master station type, deployment task metadata, and platform deployment policy configuration.

[0079] Deployment strategy types generally include: (1) Automatic deployment master station, which requires no manual intervention and the platform directly completes transmission and takes effect; (2) Approval deployment master station, where the configuration needs to be submitted for review; (3) Batch scheduled deployment master station, which is uniformly executed daily or within each cycle window; (4) Third-party forwarding deployment type, where the platform first transmits to the intermediate proxy node and the proxy forwards to the master station. The system supports presetting the deployment strategy identifier for each master station in the master station configuration table, and the deployment strategy judgment unit dynamically determines the deployment path by reading this field or based on the master station attributes.

[0080] The deployment strategy judgment unit outputs the deployment strategy type code and passes it to the transmission control unit. The transmission control unit selects different transmission paths and control behaviors according to this strategy type. For the automatic deployment master station, the transmission control unit directly calls the interface to push the configuration file; for the approval deployment master station, the system first saves the file in the temporary directory and submits an approval task to the master station interface, waiting for manual confirmation; for the scheduled deployment master station, the transmission control unit adds the configuration file to the deployment queue, marks the deployment window time, and triggers batch transmission when it expires; for the proxy transfer type deployment, the system sends the configuration data to the middleware interface and confirms the received response.

[0081] Before executing the transmission, the transmission control unit performs pre-deployment verification operations, including: (1) Checking the integrity of the configuration file; (2) Testing the transmission channel (such as the connectivity of the target interface); (3) Pre-verifying the return of the master station interface (such as verifying whether the token has expired). Only after all verification items pass, the system allows the transmission control unit to perform the deployment action. During the transmission process, the platform records the transmission status, response results, and return codes, and the transmission control unit updates the deployment status flag according to the response information.

[0082] When the deployment fails, the transmission control unit has a retry control mechanism and a timeout protection mechanism. The platform allows configuring the maximum number of retries, retry intervals, and alarm levels after failure. If the deployment response is abnormal or times out, the system will decide whether to allow retries or transfer to manual processing according to the deployment strategy type.

[0083] The platform supports parameterized configuration and rule extension for the deployment strategy judgment unit and the transmission control unit. For example, users can define deployment strategy details such as "must be manually reviewed", "two copies need to be copied for deployment", and "TLS certificate verification is required for the intermediate station" for a certain type of master station. After being recognized by the deployment strategy judgment unit, the corresponding behaviors of the transmission control unit are triggered to ensure the compliance and consistency of the deployment process.

[0084] Data interaction is carried out between two units through a deployment task structure. The task structure includes fields such as master station identifier, target path, deployment type, configuration version, deployment time window, etc. The system completes data flow through standard interfaces. In terms of the module deployment architecture, the two units can be deployed as services of the same process or exist as independent services with HTTP / RPC interfaces in a microservices architecture, with strong expansion and integration capabilities.

[0085] In summary, in the scheduling platform system of the present invention, the deployment execution unit of the configuration deployment module includes a deployment policy judgment unit for judging the type of the target master station deployment policy, and a transmission control unit for performing corresponding transmission operations based on the deployment policy type. This design enables the platform to achieve a configuration file transmission process with configurable policies, controllable paths, and auditable behaviors under different master station types and deployment scenarios, and is a key component module for improving the intelligent level and adaptation flexibility of system deployment.

[0086] Please refer to Figure 3 、 4 In the scheduling platform system of the present invention, the configuration deployment module further includes an abnormal trend recognition module for monitoring the abnormal trend during the deployment process and generating warning information. This module is used to analyze the system response, communication behavior, and task status changes during the configuration data deployment process in real time to identify potential abnormal deployment trends and trigger corresponding warning mechanisms. Its design purpose is to timely detect failure signs, response anomalies, or configuration loading delays before, during, or after the configuration transmission stage, thereby improving the controllability and prevention ability of the platform for the deployment process.

[0087] Multiple abnormal modes may occur during the deployment process, including configuration file transmission failure, master station interface response timeout, ineffective configuration loading, master station data backhaul interruption, etc. If the above problems are not identified in time, it may cause the scheduling system to be unable to access new devices normally, affecting the operation reliability. Therefore, the abnormal trend recognition module collects system operation data in two ways, passive listening and active sampling, during the deployment execution process for deployment trend analysis.

[0088] The working mode of the module is as follows: Each time the system initiates a configuration deployment task, the deployment execution unit registers information such as the task ID, target master station identifier, configuration version, planned deployment time, etc. into the deployment status table. The abnormal trend recognition module listens to the status change events corresponding to the task and reads the task status snapshots at a preset sampling period, including key indicators such as the current status (deploying, deployment successful, failed, waiting for confirmation), response time, return code, retry times, deployment result confirmation delay, etc.

[0089] The module has a built-in set of abnormal trend judgment rule libraries to monitor feature and identify trends in the following situations: If two consecutive deployment tasks fail for the same master station, it is judged as "interface stability risk"; If the average deployment response time of the master station exceeds the set threshold (e.g., 5 seconds), it is judged as "master station timeout warning"; If the deployment tasks continuously enter the "awaiting approval" state multiple times and the approval response is delayed beyond the set value, it is judged as "manual intervention bottleneck"; If there is no data upload record within 30 minutes after the master station is deployed, it is judged as "configuration loading failure risk" in combination with the communication link status.

[0090] Each type of abnormal trend corresponds to a number and an alarm level. The abnormal trend recognition module immediately generates structured alarm information after the recognition result is confirmed. The alarm information includes task ID, master station name, abnormal type, determination time, abnormal level, and recommended handling strategy. The system writes the alarm information into the platform alarm bus and pushes it to the configuration operation and maintenance interface, and at the same time records it in the historical deployment log for subsequent analysis.

[0091] The module also supports time window aggregation analysis of deployment abnormal trends. That is, within the specified time period, the number of master station deployment failures, average response time, manual processing ratio and other dimensions are counted to generate a trend curve graph and a risk assessment report for engineers to evaluate the platform operation stability. The system can set thresholds. Once the abnormal indicators of the master station exceed the set limit within a certain period, the deployment throttling mechanism is automatically triggered to suspend the subsequent deployment of the master station until the problem is investigated.

[0092] The abnormal trend recognition module can independently configure monitoring rules. The platform allows users to adjust parameters such as "failure times threshold", "timeout response value", and "approval response time upper limit" according to the business scenario to improve the adaptability of the module. The module performs non-intrusive monitoring on the deployment tasks without affecting the operation efficiency of the main deployment process; at the same time, the recognition behavior can be executed concurrently, supporting large-scale task parallel analysis.

[0093] The output interface of the module is uniformly in JSON format. The field structure includes abnormal number, deployment task identifier, master station ID, timestamp, abnormal type, severity level, recommended action, etc., for the platform log service, message push, API interface or third-party platform to call to achieve cross-system linkage.

[0094] In summary, in this embodiment, the configuration deployment module further includes an abnormal trend recognition module for monitoring abnormal trends during the deployment process and generating alarm information. Through the collection of process indicators and trend judgment of the deployment tasks, this module can identify deployment failure risks, interface abnormal fluctuations or configuration loading problems in advance, and generate high-confidence structured alarm information for the operation and maintenance system. This mechanism enhances the deployment stability and engineering manageability of the platform, and is applicable to the dynamic risk monitoring requirements of large-scale heterogeneous master station deployment and configuration task execution processes in complex environments.

[0095] Please refer to Figure 3 In the scheduling platform system of the present invention, the configuration and deployment module further includes a security control policy module for enabling the security control policy when the deployment failure reaches the threshold. The role of this module is to automatically enable the system-level protection mechanism in the case of frequent occurrence of deployment exceptions, unstable system state or continuous abnormal response of the master station, so as to avoid the platform continuously sending configuration requests to the faulty master station, causing scheduling interference or resource waste.

[0096] During the configuration and deployment process of the system, the deployment execution unit manages the execution and feedback of deployment tasks. Information such as the execution status, transmission result, master station response time, and failure times of each task is recorded in the deployment status table. The abnormal trend recognition module analyzes potential problems based on the changes in the deployment status and outputs an abnormal trend warning. If the consecutive deployment failure times exceed the preset threshold, or the failure mode occurs concentratedly on a certain type of master station or devices in a certain area, the system determines that there is a deployment risk, and the security control policy module immediately responds and triggers the control mechanism.

[0097] The deployment failure threshold can be configured in multiple dimensions, including: (1) The number of consecutive failed tasks within a unit time (such as 3 times / 10 minutes); (2) The number of consecutive failures of a single master station (such as 5 times of unsuccessful responses); (3) The proportion of deployment failures of the same type of devices in the area exceeding the set percentage (such as a 70% failure rate); (4) The deployment failure level is "seriously abnormal" and lasts for more than the set period (such as continuous abnormality for 30 minutes).

[0098] Once the system determines that the above threshold is triggered, the security control policy module will perform one or more of the following operations: 1. Forcefully suspend the deployment task: The system automatically suspends the execution of tasks related to the target master station or area in the deployment task queue, and the task status is marked as "suspended - pending security confirmation".

[0099] 2. Switch to the manual deployment process: Mark the deployment policy as "manual approval first", and subsequent deployments can only be executed after manual review and approval. A prompt will pop up on the system interface and the task modification entry will be locked.

[0100] 3. Limit the deployment frequency: In the case where the deployment is not completely suspended, the system automatically extends the task scheduling interval or limits the total number of deployment requests within a unit time to reduce the impact on the master station system.

[0101] 4. Cut off the deployment channel: When the deployment exception level reaches the highest level (such as interface response rejection, message exception, etc.), the system can automatically disconnect the deployment communication interface with the target master station to prevent continuous invalid or dangerous operations.

[0102] 5. Issue platform-level security alerts: Generate "Deployment Security Control Alert" records and push them to the platform operation and maintenance end or the security control center for manual confirmation and intervention.

[0103] The security control policy module supports the policy template management function. The system presets multiple control policy templates. Administrators can select applicable policies according to business levels, master station tolerances, and deployment importance, or customize policy combinations. The control policies can be configured in modes such as "automatically enabled / manually restored", "manually enabled / manually confirmed", "continuously frozen / detected by period", etc.

[0104] The module outputs structured control action logs externally, and the records include: trigger time, trigger threshold type, target master station ID, task scope involved, name of the enabled control policy, operation actions, status changes, whether it is lifted, etc. The log content supports docking with the platform alert center, operation and maintenance audit system, and third-party security linkage platform.

[0105] To avoid false triggers or affecting normal operations, the module also supports the "whitelist configuration" and "debugging mode" mechanisms. When the system is in the debugging or testing environment, or a specific master station is set to the trust mode, deployment failures will not trigger control actions, but detection and alert behaviors will still be retained to ensure that security policies do not interfere with normal project deployments.

[0106] In summary, in this embodiment, the configuration deployment module further includes a security control policy module for enabling security control policies when the number of deployment failures reaches the threshold. Based on the real-time monitoring and trend judgment mechanism of deployment exception metrics, this module performs security actions such as deployment suspension, approval control, and communication channel protection. It has the ability of automatic triggering and the flexibility of policy configuration, and can be used to build a self-protection closed-loop system for the scheduling platform deployment system, improving the overall system operation stability and risk prevention and control capabilities, and is applicable to key scenarios with high requirements for deployment security such as electric power, energy, and industry.

[0107] In the description of this specification, the descriptions referring to terms such as "one embodiment", "some embodiments", "illustrative embodiments", "examples", "specific examples", or "some examples" etc. mean that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in a suitable manner in any one or more embodiments or examples.

[0108] Although the embodiments of the present invention have been shown and described, those of ordinary skill in the art can understand that various changes, modifications, substitutions, and variations can be made to these embodiments without departing from the principles and spirit of the present invention. The scope of the present invention is defined by the claims and their equivalents.

Claims

1. An automatic configuration method for dispatching access of substation equipment, characterized in that, Including: A. Obtain communication data from substation equipment, where the communication data includes frame structure fields; B. Based on the frame structure fields, identify the communication protocol type by comparing the start identifier, function code field, and frame length field; C. Combine the communication protocol type with the device attribute fields to match the access configuration policy template, which includes a set of communication parameters, interface adaptation rules, and signal mapping relationships; D. Generate a structured configuration data file according to the configuration policy template; E. Deploy the configuration data file to the dispatching system to complete device communication registration and data interaction initialization.

2. A dispatching platform system for automatic access configuration of substation equipment, characterized in that, Including: A communication protocol identification module, which is used to extract communication data fields and identify the communication protocol type; A configuration policy generation module, which is used to generate an access configuration policy according to the communication protocol type and device attributes; A configuration data generation module, which is used to generate a structured configuration data file based on the configuration policy; A configuration deployment module, which is used to deploy the configuration data file to the dispatching master station system.

3. The method or platform according to claim 1 or 2, wherein The identification of the communication protocol type includes: Extract the start identifier, frame length field, and function code field in the communication data; Compare the extracted fields with a preset protocol feature library to determine the adopted communication protocol type.

4. The method or platform according to claim 1 or 2, wherein When the device attribute fields are missing, the platform executes a field scoring mechanism and triggers a field completion logic to generate a complete configuration policy.

5. The method or platform according to claim 4, wherein, The field scoring mechanism includes: Set weight factors for multiple device fields; Calculate the total score value based on the matching situation between the uploaded fields and the template fields; Compare the total score value with a set threshold; If the score value is lower than the threshold, call the default field template to complete the missing fields.

6. The method or platform according to claim 1 or 2, wherein The structured configuration data file includes a communication point table, a link parameter set, and a signal mapping table, and is output in JSON format, SCD format, or extended configuration language format.

7. The method or platform according to claim 1 or 2, wherein The configuration deployment module supports: Local deployment method; Network interface remote push deployment method; Multi-site batch deployment method; And support automatically adapting to multiple interface protocol types of the dispatching system.

8. The method or platform according to claim 1 or 2, wherein Before deployment, the platform collects parameters such as the length of the master station task queue, the running load ratio, and network latency, and based on the deployment policy decision model, determines the deployment mode as immediate deployment, delayed deployment, or batch deployment.

9. The method or platform according to claim 1 or 2, wherein, After device access, the platform performs trend analysis on the operating parameters based on a sliding time window; when at least two key parameters exceed the set threshold in multiple consecutive sampling periods and there is no reverse falling trend, an anomaly identification mechanism is triggered.

10. The method or platform according to claim 1 or 2, wherein, When the platform detects deployment failure, communication anomaly, or operating anomaly, it automatically triggers a configuration version control mechanism, rolls back the deployment configuration to the previous valid version, and records the anomaly time point and configuration change log.

Images