Crc independent calculation and check method based on iec61850 online model

Abstract

The application belongs to the technical field of substation operation and maintenance, and discloses a CRC independent calculation and checking method based on an IEC61850 online model, which comprises the following steps: creating an IED connection object and initializing an error processing container before communication; inputting the IP address and MMS port number of the IED during the connection establishment process and confirming the connection state according to the return value; sequentially obtaining a logical node directory, a data object directory and a data attribute directory after the communication is established, and storing them in a linked list structure; calling an interface function to obtain the name, sAddr and data type of the data attribute, and writing a preset placeholder when the sAddr is not returned; uniformly encoding, character set unification and sequential ordering the extraction result according to the engineering application model specification; respectively calculating the CRC values of the running model and the SCD file, and constructing the CRC structure of the attribute level, object level, logical node level and device level through hierarchical folding; when the comparison is inconsistent, locating the difference branch and executing file calling or online re-reading, and outputting the result to the background system for recording.

Description

Technical Field

[0001] This invention belongs to the field of substation operation and maintenance technology, specifically a method for independent CRC calculation and verification based on the IEC61850 online model. Background Technology

[0002] Smart substations are an important component of power grid automation. Their safe operation is not only related to the stability of the power system, but also to the safety of operation and maintenance personnel. With the widespread application of the IEC 61850 standard, the operation model and configuration files of substations have gradually become standardized. Functions such as version management, text comparison and configuration file download of SCD files have been applied in engineering practice. Related software tools can realize the consistency check of configuration files to a certain extent, providing support for engineering commissioning and maintenance.

[0003] However, many problems still exist in practical applications. First, it is difficult to obtain the configuration files of secondary devices. Different manufacturers often use proprietary summoning protocols and lack a unified interface, which leads to obstacles in obtaining and comparing configuration files across devices. Second, the configuration summoning of the entire site is usually time-consuming and cumbersome, which increases the workload of operation and maintenance. Third, existing methods mostly rely on offline SCD files for verification and judge differences by overall CRC or text comparison, which is difficult to reflect the real-time status of the running model and cannot locate specific logical nodes, data objects or data attributes, thus making the difference investigation efficiency low.

[0004] Existing technologies for verifying the consistency between the operation model and configuration file of smart substations have shortcomings such as difficulty in obtaining configuration files, low comparison efficiency, and inaccurate difference location, and cannot yet meet the needs for real-time and refined consistency verification of the operation status. The CRC calculation method specified in the current GBT32890-2016 "Engineering Application Model of IEC61850 for Relay Protection" is based on the SCD file structure to generate node hierarchy for verification. Its data source has a different correspondence with the online communication structure of the operating model. When accessing the IED operating model via the IEC61850 communication protocol, some communication parameters, such as goose and sv control block information, are not directly defined in the standard SCD node, making it difficult to adopt a unified standard CRC calculation path. Summary of the Invention

[0005] The purpose of this invention is to provide a method for independent calculation and verification of CRC based on the IEC61850 online model, so as to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a method for independent CRC calculation and verification based on the IEC61850 online model, characterized by comprising the following steps: Independent CRC calculation means that after the client completes the parsing of the IED operating model, it independently generates the CRC check value in its local computing environment, which is independent of the operating environment of the IED device. The client extracts the structured fields from the running model through a dedicated parsing module, assembles each field into a byte stream in a preset order, and performs calculations using the same CRC algorithm to achieve bidirectional verification between the running model and the client. This method avoids consuming computing resources on the IED end and can perform consistency comparisons in offline or batch scenarios, thereby ensuring the stability and universality of the verification process.

[0007] Create an IED connection object on the client and initialize an error container for establishing communication and storing error codes; Establish a communication connection with the IED using the IEC61850MMS protocol. During the connection establishment process, set the IP address and MMS port number of the IED, and confirm whether the communication is successful based on the return value. After the communication connection is established, the IED operation model is parsed layer by layer according to the hierarchical relationship of server, logical node, data object and data attribute, and the logical node directory, data object directory and data attribute directory are obtained in sequence, and the parsing results are stored as a linked list structure. Extract the data attributes obtained from the parsing, including their name, sAddr, and data type. If a data attribute does not have a defined sAddr, fill in a preset placeholder to ensure the integrity of the field. Keep the above information in a linked list for subsequent processing. According to the GBT32890-2016 Relay Protection IEC61850 Engineering Application Model Specification, the fields are uniformly encoded, character sets are consistent, and sequentially sorted to form a deterministic data sequence, avoiding comparison failures caused by differences in field representations or document comments between different manufacturers' equipment. The first CRC value of the running model is calculated for the data sequence. At the same time, the corresponding SCD configuration file is parsed and a second CRC value is generated according to the same field extraction, unified encoding and sorting rules. The first CRC value and the second CRC value are compared. A hierarchical CRC structure containing data attribute level CRC, data object level CRC, logical node level CRC and device level CRC is constructed based on a hierarchical folding method for difference location. When the first CRC value matches the second CRC value, it is confirmed that the IED operating model is consistent with the SCD configuration file; when they do not match, the specific logical node, data object or data attribute is located according to the hierarchical CRC structure, and file recall or online reading is triggered only for the located difference branch. The final comparison result, difference location and alarm information are output to the background system for recording and prompting. When the CRC comparison results are inconsistent, the client determines the location of the difference based on the layered CRC structure and automatically generates a parameter recall command. The instruction contains the corresponding logical device, logical node, and data attribute identifier. After receiving the instruction, the IED returns the real-time parameter data for that part. The client generates a difference detail based on the returned result and uploads it to the backend management system. The backend system automatically creates a defect work order based on the difference content and pushes it to the corresponding maintenance team. After the maintenance personnel complete the processing, the client can execute the verification process again until the running model is consistent with the standard configuration file, realizing the whole process management from difference discovery to closed-loop verification.

[0008] Preferably, before establishing a communication connection, the client needs to complete the initialization preparations before communication, including creating an IED connection object and initializing an error handling container; The IED connection object is the core handle for establishing communication between the client and the IED. It is used to maintain the subsequent MMS protocol session and ensure that all kinds of directory requests, data extraction and verification operations during the communication process are supported by a unified session carrier. If the connection object is not created correctly, subsequent operations cannot be carried out. Therefore, the validity of the object creation result must be confirmed during the initialization phase. The error handling container is a type of data structure used to store error codes and description information generated during communication. The purpose of initializing this container is to ensure that error information can be recorded and output at each stage, such as connection, directory acquisition, data extraction, and resource release, forming a unified diagnostic mechanism. Through this container, specific error identifiers can be captured in cases such as connection failure, node non-existence, or missing attributes, thereby providing a reliable basis for subsequent difference location and background recording. First, an IED connection object is created; if creation is successful, the error handling container is initialized; if any step fails, the subsequent communication establishment process is stopped and an error message is output. This sequential execution ensures that the preconditions for model extraction and verification are deterministic, avoiding unpredictable errors caused by directly entering the communication stage in an uninitialized state.

[0009] Preferably, after completing the initialization before communication, the client enters the communication establishment phase. The core operation of this phase is to establish an MMS protocol connection with the target IED through interface functions; Specifically, when the client calls the interface function, it needs to input the IP address of the IED and the MMS port number. The IP address is used to identify the network location of the target device, and the MMS port number is usually 102, which is used to identify the listening entry of the IEC61850MMS service. After the call is completed, the interface function will return a numerical result indicating the execution status of the connection attempt. When the return value is zero, it indicates that the TCP handshake and MMS session have been established and the communication link between the client and the IED is available. When the return value is non-zero, it indicates that the connection has failed. Possible reasons include invalid IP address, incorrect port number configuration, or underlying network interruption. In this case, the return value is written to the error handling container initialized in the previous stage, and a readable error description can be output in combination with the error type. In this way, all reasons for connection failure can be captured and stored in a unified manner, providing support for subsequent troubleshooting and background log management. In terms of execution logic, this stage relies on the IED connection object created in stage 1 and the initialized error handling container. The connection object provides a communication context for the interface functions, and the error handling container provides a recording exit for failure scenarios. The initialization of both is a necessary prerequisite to ensure that the connection establishment result is determinable and traceable.

[0010] Preferably, after the communication connection is successfully established, the client enters the hierarchical resolution phase of the running model. The goal of this phase is to sequentially obtain the logical node directory, data object directory, and data attribute directory inside the IED and form a hierarchical structure consistent with the SCD file. Specifically, the client first calls the interface function to obtain the logical node directory, thereby obtaining the identification information of each logical node under the device. Then, based on the logical node, it further calls the interface function to obtain the data object directory under it, so as to gradually expand to a more granular level. Finally, for each data object, it calls the interface function to obtain its data attribute directory, thereby completely extracting the underlying data attribute set in the running model. The directory information is organized according to the hierarchical relationship of server—logical node—data object—data attribute. The information at each level is stored through a linked list structure. The linked list not only ensures the sequential traversal of directory items, but also provides a unified data access interface for subsequent field extraction and CRC verification. In the actual traversal process, each level of the linked list is managed as a subset of the nodes of the previous level linked list, thus maintaining consistency with the hierarchical definition of the IEC61850 model in terms of data structure. Logically, this stage directly depends on the communication establishment results of the previous stage: the directory retrieval interface can only be correctly called and return valid data if the connection object is available. At the same time, the linked list storage results of this stage will serve as the input for data attribute extraction and field normalization in subsequent steps. Therefore, its data integrity and hierarchical organization are crucial for the consistency verification of the entire process.

[0011] Preferably, after the directory parsing is completed, the client enters the data attribute extraction stage. The goal of this stage is to call the interface function one by one for each attribute in the data attribute directory, extract its attribute name, sAddr and data type, and form a structured set that can be used for subsequent comparison. Specifically, the client first calls the interface function for each data attribute to obtain its name, so as to clarify the identifier of the attribute in the running model; then it calls the interface function to try to obtain the sAddr field of the attribute, which is used to represent its address mapping relationship on the device side; finally, it calls the interface function to obtain the data type of the attribute to distinguish between boolean, string or other types. In the actual parsing process, there may be cases where some data attributes do not define sAddr. In order to ensure the integrity of the field and the determinism of subsequent processing, when a missing sAddr is detected, a preset placeholder is uniformly written to replace the field, thereby ensuring that each attribute record consists of three elements: "name, sAddr (or placeholder), and data type". All extraction results are stored in a linked list structure according to the hierarchical relationship of the directory parsing stage. Each linked list node contains the attribute name, the corresponding sAddr or placeholder, and the data type of the attribute. The linked lists are linked by pointers to achieve sequential traversal. This design not only preserves the hierarchical structure of the running model, but also ensures the consistency of data access. The results stored in the linked list can not only directly participate in subsequent normalization and CRC verification, but also quickly locate the specific difference attribute by traversing the linked list when the comparison fails. This stage builds upon the directory parsing results of the previous stage: only by obtaining a complete list of data attributes through the directory can they be extracted and completed one by one. The linked list structure output by this stage serves as the input for field encoding and sorting in the next stage, thus forming a series of interconnected links in the overall process.

[0012] Preferably, during the specific execution of data attribute extraction, the client needs to call the interface function for each parsed data attribute in sequence to obtain the name, sAddr, and data type of the attribute. When the interface function is called, if it can return sAddr normally, the value is directly recorded into the linked list node; if the interface function does not return sAddr or the return value is empty, a preset placeholder is written in the field position to ensure the integrity of the record structure and the stability of subsequent processing. In terms of the structure of the linked list nodes, each node contains three types of deterministic information: attribute name field, sAddr field (or alternative placeholders), and data type field. All nodes are linked sequentially according to the original hierarchical order to form a traversable data linked list. This linked list not only maintains the hierarchical relationship of the attribute set in the running model, but also ensures that even if some attributes do not define sAddr, the overall linked list remains complete and consistent in terms of structure and number of fields.

[0013] Preferably, after completing the data attribute extraction and field normalization processing, the client enters the consistency verification stage of the running model. The core of this stage is to generate CRC check values ​​for the running model and the SCD configuration file respectively, and to locate the differences through hierarchical structured CRC comparison. Specifically, firstly, based on the normalized data sequence stored in the aforementioned linked list, the CRC operation module is called to calculate the first CRC value of the running model. At the same time, the same processing flow is performed on the corresponding SCD configuration file, that is, according to the field extraction, unified encoding and sequential sorting rules consistent with the running model, another deterministic normalized data sequence is generated, and the second CRC value is calculated on it. Since the data at both ends are completely consistent in extraction and processing rules, the reproducibility and determinism of the comparison results are guaranteed. During the comparison process, if the first CRC value and the second CRC value are completely consistent, it indicates that the running model and the SCD configuration file are consistent at the field level. If they are inconsistent, the construction of a hierarchical CRC structure is further triggered. Specifically, the lower-level CRC values ​​are folded and calculated in the order of data attribute level, data object level, logical node level, and device level, and summarized to the upper-level CRC node, thus forming a bottom-up hierarchical CRC structure. This hierarchical CRC structure can gradually narrow the range of differences when the comparison results are inconsistent, until the specific data attribute, data object, or logical node is located.

[0014] Preferably, after the comparison of the first CRC value and the second CRC value is completed, the client performs difference processing based on the comparison result. If the first CRC value of the running model is completely equal to the second CRC value of the SCD configuration file, it indicates that the two are consistent at all levels of logical nodes, data objects and data attributes. At this time, it can be determined that the running model of the IED is consistent with the configuration file, and the verification process ends. If the first CRC value and the second CRC value are not equal, it indicates that there is a difference between the running model and the configuration file. At this time, the system uses the hierarchical CRC structure built in the previous stage to expand from top to bottom. By comparing the data attribute level CRC, data object level CRC and logical node level CRC, the branch where the difference is located is accurately located. Once the specific logical node, data object or data attribute is determined, the client only performs further operations on the branch with the difference, without re-parsening the entire model. The specific operations include: calling the file recall interface to reread the corresponding configuration file fragment, or calling the online reading interface to directly obtain the latest data from the IED running model, thereby re-checking the branch with the difference. Finally, this stage outputs the comparison results, the location of differences, and the processing information to the backend system and records them in the log for subsequent operation analysis and problem tracing. In this way, differences can not only be accurately located, but also be recorded and retained in a timely manner, forming a complete difference management and tracking mechanism.

[0015] The beneficial effects of this invention are as follows: 1. This invention, by creating an IED connection object and configuring a unified error handling container during the communication initialization phase, enables the client to classify and centrally record various return values ​​when establishing MMS communication with the IED. This structure achieves unified management of the communication link status and forms a traceable runtime context, providing a complete communication foundation for subsequent directory parsing and data extraction. Compared with methods that rely on offline SCD files for static comparison, this scheme directly applies to the real-time runtime model of the device, reflecting the actual configuration status in an online environment. It avoids comparison deviations caused by asynchronous file updates, providing a reliable data entry point and communication guarantee for consistency verification.

[0016] 2. This invention obtains logical nodes, data objects, and data attributes step by step by calling MMS interface functions in a hierarchical manner, and uses a linked list structure for storage management. When an undefined sAddr field is detected, the system automatically writes a placeholder and marks the field to maintain the integrity of the hierarchical structure. Through a unified data organization method, the system can maintain a consistent extraction format under different manufacturers and different equipment models, shielding the differences in implementation among manufacturers. The data processed by this mechanism has the characteristics of stable structure and controllable order, providing standardized input for CRC encoding and comparison, and ensuring the integrity and reproducibility of input data in multi-source and multi-scenario environments.

[0017] 3. This invention, based on the IEC61850 engineering model specification, uniformly encodes and sorts the extracted fields to generate a deterministic data sequence, and then calculates the CRC values ​​of the running model and the benchmark SCD file. The system adopts a layered and folded CRC structure to achieve difference location from the attribute level to the device level. When the comparison is inconsistent, only the difference branch is triggered to trigger file recall or online reread operation, and the result is synchronized to the background system. The background system automatically generates a defect work order and associates the difference node to achieve closed-loop management of detection, location and rectification. This mechanism avoids repeated parsing of all files, improves the efficiency of difference processing, and ensures that the consistency between the running model and the configuration file can be verified and maintained in real time and accurately. Attached Figure Description

[0018] Figure 1 This is the overall verification flowchart of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] like Figure 1 As shown, this embodiment of the invention provides a method for independent CRC calculation and verification based on the IEC61850 online model, including the following steps: Create an IED connection object on the client and initialize an error container for establishing communication and storing error codes; Establish a communication connection with the IED using the IEC61850MMS protocol. During the connection establishment process, set the IP address and MMS port number of the IED, and confirm whether the communication is successful based on the return value. After the communication connection is established, the IED operation model is parsed layer by layer according to the hierarchical relationship of server, logical node, data object and data attribute, and the logical node directory, data object directory and data attribute directory are obtained in sequence, and the parsing results are stored as a linked list structure. Extract the data attributes obtained from the parsing, including their name, sAddr, and data type. If a data attribute does not have a defined sAddr, fill in a preset placeholder to ensure the integrity of the field. Keep the above information in a linked list for subsequent processing. According to the GBT32890-2016 Relay Protection IEC61850 Engineering Application Model Specification, the fields are uniformly encoded, character sets are consistent, and sequentially sorted to form a deterministic data sequence, avoiding comparison failures caused by differences in field representations or document comments between different manufacturers' equipment. The first CRC value of the running model is calculated for the data sequence. At the same time, the corresponding SCD configuration file is parsed and a second CRC value is generated according to the same field extraction, unified encoding and sorting rules. The first CRC value and the second CRC value are compared. A hierarchical CRC structure containing data attribute level CRC, data object level CRC, logical node level CRC and device level CRC is constructed based on a hierarchical folding method for difference location. When the first CRC value matches the second CRC value, it confirms that the IED operating model is consistent with the SCD configuration file; when they do not match, the specific logical node, data object or data attribute is located according to the hierarchical CRC structure, and file recall or online reading is triggered only for the located difference branch. The final comparison result, difference location and alarm information are output to the background system for recording and prompting.

[0021] Before establishing a communication connection, the client needs to complete the initialization preparations for communication, including creating an IED connection object and initializing an error handling container. The IED connection object is the core handle for establishing communication between the client and the IED. It is used to maintain the subsequent MMS protocol session and ensure that all kinds of directory requests, data extraction and verification operations during the communication process are supported by a unified session carrier. If the connection object is not created correctly, subsequent operations cannot be carried out. Therefore, the validity of the object creation result must be confirmed during the initialization phase. The error handling container is a type of data structure used to store error codes and description information generated during communication. The purpose of initializing this container is to ensure that error information can be recorded and output at each stage, such as connection, directory acquisition, data extraction, and resource release, forming a unified diagnostic mechanism. Through this container, specific error identifiers can be captured in cases such as connection failure, node non-existence, or missing attributes, thereby providing a reliable basis for subsequent difference location and background recording. The execution order of this step is as follows: First, create the IED connection object; if the creation is successful, continue to initialize the error handling container; if any step fails, stop the subsequent communication establishment process and output error information. By executing this order, the preconditions for the extraction and verification of the running model are deterministic, avoiding unpredictable errors caused by directly entering the communication stage in an uninitialized state. During implementation, the CRC16-CCITT-FALSE algorithm is preferred for verification; the generator polynomial of this algorithm is x¹6 +x¹²+x 5 +1 (hexadecimal 0x1021), the initial value is 0xFFFF, the input and output are not reversed, and the calculation result is not XORed; This algorithm strikes a good balance between computational accuracy and execution efficiency, and is suitable for validating multi-level, long-field data in the IEC61850 model. Its verification objects include key fields such as IED identifier, logical node, data object, data attribute and sAddr communication address, in order to ensure the overall integrity and reproducibility of the running model; Phase 1: Initialization Preparation (Building the Basic Client Environment) Objective: To create connection objects and an error container in preparation for subsequent communication. Core API: IedConnection IedConnection_create(void): Creates an IedConnection instance (the core handle for client-to-IED communication).

[0022] void IedClientError_init(IedClientError error): Initializes the error container (stores the error code and description for subsequent operations).

[0023] Implementation code snippet: #include "iec61850_client.h" #include "linked_list.h" #include<stdio.h> int main() { / / 1. Initialize the connection object and error container IedConnection con = IedConnection_create(); / / Create a connection handle IedClientError error; IedClientError_init(&error); / / Initialize error messages Unlike existing technologies that rely solely on offline SCD files for consistency verification, this embodiment establishes a dedicated connection handle and a unified error container during the initialization phase of the online running model. This ensures that subsequent directory parsing, field extraction, normalized encoding, and hierarchical CRC verification all depend on this initialization result, thus creating a fundamental difference from existing file comparison schemes in terms of data source, execution path, and error diagnosis mechanism.

[0024] After completing the initialization before communication, the client enters the communication establishment phase. The core operation of this phase is to establish an MMS protocol connection with the target IED through interface functions; Specifically, when the client calls the interface function, it needs to input the IP address of the IED and the MMS port number. The IP address is used to identify the network location of the target device, and the MMS port number is usually 102, which is used to identify the listening entry of the IEC61850MMS service. After the call is completed, the interface function will return a numerical result indicating the execution status of the connection attempt. (2) Phase 2: Establishing an IED connection (client and IED communication handshake) Objective: To establish a TCP connection with the IED via IP address and port (default MMS port 102) and verify the validity of the communication link; Core API: int IedConnection_connect(IedConnection con, IedClientError error, const char hostname, int port): Parameters: con (connection handle), error (error container), hostname (IP address of IED), port (MMS port, default 102).

[0025] Return value: 0 indicates success, non-zero indicates failure (error information is stored in error).

[0026] Key processing: If a connection fails, the error type needs to be determined: IP / port error (IED_ERROR_CONNECTION_REFUSED), network outage (IED_ERROR_NETWORK_ERROR), etc. A readable error description can be obtained through IedClientError_toString(&error).

[0027] Implementation code snippet: / / 2. Establish an IED connection (Example: IEDIP=192.168.1.100, port=102) const char iedIp = "192.168.1.100"; int iedPort = 102; int connectRes = IedConnection_connect(con,&error, iedIp, iedPort);if(connectRes != 0) { printf("Connection to IED failed: %s\n", IedClientError_toString(&error)); IedConnection_destroy(con); / / Release connection resources return -1; }printf("Successfully connected to IED: %s:%d\n", iedIp,iedPort); When the return value is zero, it indicates that the TCP handshake and MMS session have been established and the communication link between the client and the IED is available. When the return value is non-zero, it indicates that the connection has failed. Possible reasons include invalid IP address, incorrect port number configuration, or underlying network interruption. In this case, the return value is written to the error handling container initialized in the previous stage, and a readable error description can be output in combination with the error type. In this way, all reasons for connection failure can be captured and stored in a unified manner, providing support for subsequent troubleshooting and background log management. In terms of execution logic, this stage relies on the IED connection object created in stage 1 and the initialized error handling container. The connection object provides a communication context for the interface functions, and the error handling container provides a recording exit for failure scenarios. The initialization of both is a necessary prerequisite to ensure that the connection establishment result is determinable and traceable. Unlike existing technologies that rely solely on static configuration checks based on SCD files, this embodiment verifies the actual response status of the IED through online communication handshakes. This ensures that consistency verification is built upon a real-time operational model, avoiding link anomalies that cannot be detected by file comparison alone. It also lays a reliable communication foundation for subsequent node directory parsing, data attribute extraction, and CRC verification.

[0028] After the communication connection is successfully established, the client enters the hierarchical resolution phase of the running model. The goal of this phase is to sequentially obtain the logical node directory, data object directory and data attribute directory inside the IED, and form a hierarchical structure consistent with the SCD file. Specifically, the client first calls the interface function to obtain the logical node directory, thereby obtaining the identification information of each logical node under the device. Then, based on the logical node, it further calls the interface function to obtain the data object directory under it, so as to gradually expand to a more granular level. Finally, for each data object, it calls the interface function to obtain its data attribute directory, thereby completely extracting the underlying data attribute set in the running model. The directory information is organized according to the hierarchical relationship of server—logical node—data object—data attribute. The information at each level is stored through a linked list structure. The linked list not only ensures the sequential traversal of directory items, but also provides a unified data access interface for subsequent field extraction and CRC verification. In the actual traversal process, each level of the linked list is managed as a subset of the nodes of the previous level linked list, thus maintaining consistency with the hierarchical definition of the IEC61850 model in terms of data structure. Phase 3: Obtaining Hierarchical Nodes (Parsing from Top to Bottom Layer by Layer) This stage is crucial. It requires retrieving the node directory sequentially according to the hierarchy of "server → logical node → data object → data attribute". Each level is stored through a linked list, and the corresponding directory retrieval API and traversal API need to be called.

[0029] ① Level 1: Obtain the server logical node (LN) directory Objective: To obtain a directory list of all logical nodes (such as "MMXU1" and "CTRL1") under the IED server. Core API: LinkedList IedConnection_getLogicalNodeDirectory(IedConnection con,IedClientError error, char lnPrefixBuffer, int acsiClass): Parameters: con (connection handle), error (error container), lnPrefixBuffer (buffer storing LN prefixes, can be set to NULL to get all LNs), acsiClass (ACSI class, taking ACSI_CLASS_LOGICAL_NODE indicates getting logical nodes).

[0030] Return value: A non-NULL value indicates success. It returns a LinkedList containing the names of the Linked List nodes (each node's data field is char). (Type of LN name).

[0031] Traversal logic: Traverse the linked list using LinkedList_getNext(LinkedListself) until NULL is returned (traversal ends).

[0032] Implementation code snippet: / / 3. Level 1: Retrieve Logical Node (LN) Directory char lnPrefix

[64] = {0}; / / Stores the LN prefix, NULL indicates that all LNs are retrieved. LinkedList lnDirectory = IedConnection_getLogicalNodeDirectory(con,&error, lnPrefix, ACSI_CLASS_LOGICAL_NODE);if (lnDirectory == NULL) { printf("Failed to retrieve LN directory: %s\n", IedClientError_toString(&error)); IedConnection_close(con); IedConnection_destroy(con); return -1; printf("Successfully retrieved the LN directory, starting to traverse LN...\n"); / / Traverse the LN linked list (Note: In some libraries, lnDirectory is the head node, and the first element should start from getNext). LinkedList currentLnNode = LinkedList_getNext(lnDirectory); while (currentLnNode != NULL) { char lnName = (char `currentLnNode->data; / / Extract LN name (e.g., "MMXU1") printf("Current LN: %s\n", lnName);` ② Level 2: Retrieve the Data Object (DO) directory under the logical node Objective: For each logical node, retrieve a directory list of all data objects (e.g., "TotW", "Pos") under it. Core API: Step 1: Obtain a LogicalNode instance by LN name: LogicalNode IedConnection_getLogicalNode(IedConnection con, const char lnName).

[0033] Parameters: con (connection handle), lnName (LN name obtained from level 1).

[0034] Return value: A non-NULL value indicates success and returns a LogicalNode instance (the underlying handle for subsequent DO operations).

[0035] Step 2: Obtain the DO directory: LinkedList LogicalNode_getDataObjectDirectory(LogicalNode ln, IedClientError) (error). Parameters: ln (LogicalNode instance), error (error container).

[0036] Return value: A non-NULL value indicates success. It returns a LinkedList containing the DO names (each node's data is char). (DO name of type).

[0037] Error handling: If IedConnection_getLogicalNode returns NULL, it means that LN does not exist. You need to skip the current LN and continue to traverse the next one.

[0038] Implementation code snippet: / / 3. Level 2: Get the DO directory under the current LN LogicalNode ln = IedConnection_getLogicalNode(con, lnName); if (ln == NULL) { printf("Failed to retrieve LN instance: %s\n", lnName); currentLnNode = LinkedList_getNext(currentLnNode); / / Skip the current LN and iterate to the next one continue;} LinkedList doDirectory = LogicalNode_getDataObjectDirectory(ln,&error);if (doDirectory == NULL) { printf("Failed to retrieve the DO directory of LN[%s]: %s\n", lnName, IedClientError_toString(&error)); currentLnNode = LinkedList_getNext(currentLnNode); continue;} printf("DO directory under LN[%s]: Start traversing DO...\n", lnName); / / Traverse the DO linked list LinkedList currentDoNode = LinkedList_getNext(doDirectory); while (currentDoNode != NULL) { char doName = (char `currentDoNode->data; / / Extract DO name (e.g., "TotW") printf("Current DO: %s\n", doName);` ③ Level 3: Retrieve the Data Attributes (DAI) directory under the data object Objective: For each data object, obtain a directory list of all its data attributes (such as "stVal", "desc", "general"), and finally extract the attributes such as sAddr that the user is interested in.

[0039] Core API: Step 1: Obtain a DataObject instance by DO name: DataObject LogicalNode_getDataObject(LogicalNode ln, const char doName).

[0040] Parameters: ln (LogicalNode instance), doName (DO name obtained from level 2).

[0041] Return value: A non-NULL value indicates success and returns a DataObject instance.

[0042] Step 2: Obtain the DAI directory: LinkedList DataObject_getDataAttributeDirectory(DataObject doObj, IedClientError) (error). Parameters: doObj (a DataObject instance), error (an error container).

[0043] Return value: A non-NULL value indicates success and returns a LinkedList containing DataAttribute (DAI) instances (each node's data is a DataAttribute). type).

[0044] Step 3: Extract DAI attributes: const char DataAttribute_getName(DataAttribute dai): Retrieves the name of the DAI (e.g., "general").

[0045] const char DataAttribute_getSAddr(DataAttribute dai): Gets the sAddr attribute of DAI (e.g., "YX:B02.GSLogicLinkMult1.out1").

[0046] const char DataAttribute_getType(DataAttribute dai): Gets the DAI data type (such as "BOOLEAN" or "STRING").

[0047] Key processing: DAI's sAddr is an optional attribute, so it is necessary to check whether the return value is NULL to avoid null pointer exceptions.

[0048] Implementation code snippet: Logically, this stage directly depends on the communication establishment results of the previous stage: the directory retrieval interface can only be correctly called and return valid data if the connection object is available. At the same time, the linked list storage results of this stage will serve as the input for data attribute extraction and field normalization in subsequent steps. Therefore, its data integrity and hierarchical organization are crucial for the consistency verification of the entire process.

[0049] Unlike existing technologies that rely solely on static tree structures described in files, this embodiment obtains the directory layer by layer through an online interface to ensure the real-time performance and accuracy of the running model. Furthermore, it stores and organizes the data using a linked list structure, enabling dynamic management and release of model data. This avoids deviations caused by static configuration or inconsistent parsing. This approach generates comparison data sources directly from the device's operating status, which is fundamentally different from traditional file-based parsing schemes.

[0050] After the directory parsing is completed, the client enters the data attribute extraction stage. The goal of this stage is to call the interface function one by one for each attribute in the data attribute directory, extract its attribute name, sAddr and data type, and form a structured set that can be used for subsequent comparison. Specifically, the client first calls the interface function for each data attribute to obtain its name, so as to clarify the identifier of the attribute in the running model; then it calls the interface function to try to obtain the sAddr field of the attribute, which is used to represent its address mapping relationship on the device side; finally, it calls the interface function to obtain the data type of the attribute to distinguish between boolean, string or other types. In the actual parsing process, there may be cases where some data attributes do not define sAddr. In order to ensure the integrity of the field and the determinism of subsequent processing, when a missing sAddr is detected, a preset placeholder is uniformly written to replace the field, thereby ensuring that each attribute record consists of three elements: "name, sAddr (or placeholder), and data type". Level 3: Retrieve the DAI directory under the current DO directory. DataObject doObj = LogicalNode_getDataObject(ln, doName); if (doObj == NULL) { printf("Failed to retrieve DO[%s] instance: %s\n", doName, lnName); currentDoNode = LinkedList_getNext(currentDoNode); / / Skip the current DO continue;} LinkedList daiDirectory = DataObject_getDataAttributeDirectory(doObj,&error); if (daiDirectory == NULL) { printf("Failed to retrieve the DAI directory of DO[%s]: %s\n", doName, IedClientError_toString(&error)); currentDoNode = LinkedList_getNext(currentDoNode); continue;} printf("DAI directory under DO[%s]: Starting to extract attributes...\n", doName); / / Traverse the DAI linked list and extract attributes LinkedList currentDaiNode = LinkedList_getNext(daiDirectory); while (currentDaiNode != NULL) { DataAttribute dai = (DataAttribute)currentDaiNode->data; if (dai == NULL) { currentDaiNode = LinkedList_getNext(currentDaiNode); continue;} / / Extract key attributes of DAI const char daiName = DataAttribute_getName(dai); const char daiSAddr = DataAttribute_getSAddr(dai); const char daiType = DataAttribute_getType(dai); / / Output DAI information printf(" DAI name: %s\n", daiName); if (daiSAddr != NULL&&strlen(daiSAddr)>0) { printf(" DAI sAddr:%s\n", daiSAddr); / / Output the sAddr that the user is following} else { printf(" DAI sAddr: Undefined\n");} printf(" DAI data type: %s\n", daiType); currentDaiNode = LinkedList_getNext(currentDaiNode);} / / Release the DAI directory linked list of the current DO (to avoid memory leaks) LinkedList_destroy(daiDirectory); currentDoNode = LinkedList_getNext(currentDoNode);} / / Release the current LN's DO directory list LinkedList_destroy(doDirectory); currentLnNode = LinkedList_getNext(currentLnNode);} All extraction results are stored in a linked list structure according to the hierarchical relationship of the directory parsing stage. Each linked list node contains the attribute name, the corresponding sAddr or placeholder, and the data type of the attribute. The linked lists are linked by pointers to achieve sequential traversal. This design not only preserves the hierarchical structure of the running model, but also ensures the consistency of data access. The results stored in the linked list can not only directly participate in subsequent normalization and CRC verification, but also quickly locate the specific difference attribute by traversing the linked list when the comparison fails. This stage builds upon the directory parsing results of the previous stage: only by obtaining a complete list of data attributes through the directory can they be extracted and completed one by one. The linked list structure output by this stage serves as the input for field encoding and sorting in the next stage, thus forming a series of interconnected links in the overall process. Unlike existing technologies that simply read attribute fields directly from file configurations, this embodiment extracts attributes from the running model in real time through an online interface and ensures the integrity of data fields through a placeholder mechanism. This approach not only avoids the problem of comparison interruption caused by missing attribute definitions on the device side, but also ensures the consistency of the input format of each data entry during CRC calculation and difference location. Therefore, in terms of implementation path and data determinism, this solution is fundamentally different from existing solutions that simply rely on file content.

[0051] In the specific execution process of data attribute extraction, the client needs to call the interface function for each parsed data attribute in sequence to obtain the name, sAddr and data type of the attribute. When the interface function is called, if it can return sAddr normally, the value is directly recorded into the linked list node; if the interface function does not return sAddr or the return value is empty, a preset placeholder is written in the field position to ensure the integrity of the record structure and the stability of subsequent processing. In terms of the composition of the linked list nodes, each node contains three types of deterministic information: attribute name field, sAddr field (or alternative placeholders), and data type field. All nodes are linked in sequence according to the original hierarchical order, and finally form a traversable data linked list. This linked list not only maintains the hierarchical relationship of the attribute set in the running model, but also ensures that even if some attributes do not define sAddr, the overall linked list remains complete and consistent in terms of structure and number of fields. Unlike existing technologies that directly read attributes from file content, this embodiment emphasizes the combination of the judgment mechanism of the interface call return value and the placeholder filling mechanism. The former ensures the immediate acquisition of real attributes in the running model, while the latter ensures the consistency of processing in the case of missing fields. This dual mechanism avoids the situation where the comparison is interrupted or the result is uncertain when encountering incomplete attributes in traditional methods, laying the foundation for realizing the consistency verification of the entire chain.

[0052] After completing the data attribute extraction and field normalization process, the client enters the consistency verification stage of the running model. The core of this stage is to generate CRC check values ​​for the running model and the SCD configuration file respectively, and to locate the differences through hierarchical structured CRC comparison. Specifically, firstly, based on the normalized data sequence stored in the aforementioned linked list, the CRC operation module is called to calculate the first CRC value of the running model. At the same time, the same processing flow is performed on the corresponding SCD configuration file, that is, according to the field extraction, unified encoding and sequential sorting rules consistent with the running model, another deterministic normalized data sequence is generated, and the second CRC value is calculated on it. Since the data at both ends are completely consistent in extraction and processing rules, the reproducibility and determinism of the comparison results are guaranteed. During the comparison process, if the first CRC value and the second CRC value are completely consistent, it means that the running model and the SCD configuration file are consistent at the field level; if they are inconsistent, the construction of a hierarchical CRC structure is further triggered. Specifically, the lower-level CRC values ​​are folded and calculated in the order of data attribute level, data object level, logical node level and device level, and summarized to the upper-level CRC node, thus forming a bottom-up hierarchical CRC structure. This hierarchical CRC structure can gradually narrow the range of differences when the comparison results are inconsistent, until the specific data attribute, data object or logical node is located. Phase 4: Resource Release (Avoiding Memory Leaks and Connection Hoarding) During the field extraction and standardization phase, the system sets the IED name, LD identifier, DO type, DAI attribute value and sAddr communication address as mandatory fields, and follows the principle of "inclusion if it exists" for optional fields such as desc. If a critical field is detected to be missing, the system automatically generates an alarm and identifies the corresponding node. In response to the situation where hexadecimal and decimal are mixed in the sAddr format between different manufacturers, it is uniformly converted to decimal integers before participating in the CRC calculation to ensure the consistency of the comparison results. All fields are finally arranged in a fixed field order and lexicographical order to form a deterministic byte stream for the CRC calculation module to call. Objective: After traversal, release all linked list resources and connection handles to ensure client resource reclamation.

[0053] Core API: void LinkedList_destroy(LinkedList list): Destroys the linked list (releases memory for all nodes).

[0054] void IedConnection_close(IedConnection con): Closes the TCP connection with IED.

[0055] void IedConnection_destroy(IedConnection con): Destroys the connection handle (releases the connection instance's memory). Implementation code snippet: / / 4. Resource Release LinkedList_destroy(lnDirectory); / / Release the LinkedList (LN) directory list IedConnection_close(con); / / Close the IED connection IedConnection_destroy(con); / / Destroy the connection handle printf("Model acquisition complete, all resources released\n"); return 0;} Unlike existing technologies that rely solely on overall file CRC or line-by-line text comparison, this embodiment employs a dual-end normalization process combined with hierarchical CRC folding. On one hand, by using the same extraction and sorting rules for the running model and configuration file, the consistency of the comparison input is ensured. On the other hand, through a hierarchical CRC architecture, the comparison process is expanded from an overall value to a structured result that can be located step by step. This differentiated design avoids the problem that a single CRC value cannot reflect the difference position, laying the foundation for the accurate identification of subsequent difference branches.

[0056] After comparing the first CRC value with the second CRC value, the client performs difference processing based on the comparison result. If the first CRC value of the running model is completely equal to the second CRC value of the SCD configuration file, it indicates that the two are consistent at all levels of logical nodes, data objects and data attributes. At this time, it can be determined that the running model of the IED is consistent with the configuration file, and the verification process ends. If the first CRC value and the second CRC value are not equal, it indicates that there is a difference between the running model and the configuration file. At this time, the system uses the hierarchical CRC structure built in the previous stage to expand from top to bottom. By comparing the data attribute level CRC, data object level CRC and logical node level CRC, the branch where the difference is located is accurately located. Once the specific logical node, data object or data attribute is determined, the client only performs further operations on the branch with the difference, without re-parsening the entire model. The specific operations include: calling the file recall interface to reread the corresponding configuration file fragment, or calling the online reading interface to directly obtain the latest data from the IED running model, thereby re-checking the branch with the difference. Finally, this stage outputs the comparison results, the location of differences, and processing information to the backend system and records them in the logs for subsequent operational analysis and problem tracing. In this way, differences can not only be accurately located but also recorded and retained in a timely manner, forming a complete difference management and tracking mechanism. Compared with existing technologies, this embodiment does not perform overall file replacement or full rereading after inconsistency is found. Instead, it uses a layered CRC difference location + difference branch selective rereading method to supplement and verify only the inconsistent parts. This design significantly reduces repeated parsing and invalid communication, ensuring the accuracy and efficiency of comparison. At the same time, it achieves the traceability of differences at the data management level. This processing method is substantially different from the traditional method of overall coverage rereading. Complete core code example #include "iec61850_client.h" #include "linked_list.h" #include<stdio.h> #include<string.h> / / Log printing macro definition #define LOG_INFO(fmt, ...) printf("[INFO] " fmt "\n", ##__VA_ARGS__) #define LOG_ERROR(fmt, ...) printf("[ERROR] " fmt "\n", ##__VA_ARGS__)int main(int argc, char argv[]) { / / 1. Initialization preparation IedConnection con = IedConnection_create(); if (con == NULL) { LOG_ERROR("Failed to create IedConnection instance"); return -1;} IedClientError error; IedClientError_init(&error); / / 2. Establish IED connection (you need to pass in the actual IED's IP address and port) const char iedIp = (argc>1) ? argv[1] : "192.168.1.100"; int iedPort = (argc>2) ? atoi(argv[2]) : 102; int connectRes = IedConnection_connect(con,&error, iedIp,iedPort); if (connectRes != 0) { LOG_ERROR("Failed to connect to IED[%s:%d]: %s", iedIp, iedPort,IedClientError_toString(&error)); IedConnection_destroy(con); return -1;} LOG_INFO("Successfully connected to IED[%s:%d]", iedIp, iedPort); / / 3. Level 1: Retrieve Logical Node (LN) Directory LinkedList lnDirectory = IedConnection_getLogicalNodeDirectory(con,&error, NULL, ACSI_CLASS_LOGICAL_NODE); if (lnDirectory == NULL) { LOG_ERROR("Failed to retrieve LN directory: %s", IedClientError_toString(&error)); IedConnection_close(con); IedConnection_destroy(con); return -1} LOG_INFO("Successfully retrieved LN directories, a total of %d LNs (including head nodes)", LinkedList_size(lnDirectory)); / / Traverse the LN linked list LinkedList currentLnNode = LinkedList_getNext(lnDirectory); while (currentLnNode != NULL) { char lnName = (char currentLnNode->data; if (lnName == NULL || strlen(lnName) == 0) { currentLnNode = LinkedList_getNext(currentLnNode); continue;} LOG_INFO("\n=== Start processing LN: %s ===", lnName); / / 3. Level 2: Get the DO directory under the current LN LogicalNode ln = IedConnection_getLogicalNode(con, lnName);if(ln == NULL) { LOG_ERROR("Failed to obtain LN[%s] instance, skip this LN", lnName); currentLnNode = LinkedList_getNext(currentLnNode); continue;} LinkedList doDirectory = LogicalNode_getDataObjectDirectory(ln,&error); if (doDirectory == NULL) { LOG_ERROR("Failed to retrieve DO directory for LN[%s]: %s, skipping this LN", lnName,IedClientError_toString(&error)); currentLnNode = LinkedList_getNext(currentLnNode); continue;} LOG_INFO("LN[%s] has a total of %d DOs (including the head node)", lnName, LinkedList_size(doDirectory)); / / Traverse the DO linked list LinkedList currentDoNode = LinkedList_getNext(doDirectory); while (currentDoNode != NULL) { char doName = (char currentDoNode->data; if (doName == NULL || strlen(doName) == 0) { currentDoNode = LinkedList_getNext(currentDoNode);continue;} LOG_INFO("\n--- Start processing DO:%s (belonging LN:%s) ---", doName,lnName); / / 3. Level 3: Get the DAI directory under the current DO. DataObject doObj = LogicalNode_getDataObject(ln, doName); if (doObj == NULL) { LOG_ERROR("Failed to retrieve DO[%s] instance, skip this DO", doName); currentDoNode = LinkedList_getNext(currentDoNode);continue;} LinkedList daiDirectory = DataObject_getDataAttributeDirectory(doObj,&error); if (daiDirectory == NULL) { LOG_ERROR("Failed to retrieve DAI directory for DO[%s]: %s, skipping this DO", doName, IedClientError_toString(&error)); currentDoNode = LinkedList_getNext(currentDoNode);continue;} LOG_INFO("DO[%s] contains %d DAIs (including the head node)", doName,LinkedList_size(daiDirectory)); / / Traverse the DAI linked list and extract attributes LinkedList currentDaiNode = LinkedList_getNext(daiDirectory); while (currentDaiNode != NULL) { DataAttribute dai = (DataAttribute)currentDaiNode->data; if (dai == NULL) { currentDaiNode = LinkedList_getNext(currentDaiNode); continue;} const char daiName = DataAttribute_getName(dai); const char daiSAddr = DataAttribute_getSAddr(dai); const char daiType = DataAttribute_getType(dai); LOG_INFO("DAI name: %s | Data type: %s | sAddr: %s", (daiName != NULL) ? daiName : "Undefined", (daiType != NULL) ? daiType : "Undefined", (daiSAddr != NULL && strlen(daiSAddr)>0) ? daiSAddr : "Undefined"); currentDaiNode = LinkedList_getNext(currentDaiNode);} / / Release the DAI directory of the current DO LinkedList_destroy(daiDirectory); currentDoNode = LinkedList_getNext(currentDoNode);} / / Release the DO directory of the current LN LinkedList_destroy(doDirectory); currentLnNode = LinkedList_getNext(currentLnNode);} / / 4. Release resources: LinkedList_destroy(lnDirectory); IedConnection_close(con); IedConnection_destroy(con); LOG_INFO("\n=== Model acquisition process completed, all resources released==="); return 0;} IV. Key Precautions API Compatibility: API names may vary slightly between different vendors' IEC61850 libraries (such as libiec61850, open62541). Refer to the actual library documentation for the most accurate name (e.g., some libraries use IedClient_getLogicalNodes instead of IedConnection_getLogicalNodeDirectory). Resource Release Principles: Each linked list obtained through getXXXDirectory must be released by calling LinkedList_destroy; otherwise, it will lead to a memory leak.

[0057] Connection closing order: First IedConnection_close, then IedConnection_destroy. This order cannot be reversed.

[0058] Error handling completeness: All API calls (such as IedConnection_connect and LogicalNode_getDataObject) must check the return value to avoid null pointer access.

[0059] Obtaining the error description via `IedClientError_toString` facilitates problem localization (e.g., "Insufficient permissions," "Node does not exist"). Data type conversion: The data field of a linked list node needs to be type-casted according to the actual storage type (e.g., LN / DO name is char). DAI stands for DataAttribute Before conversion, it is necessary to check whether data is NULL.

[0060] Security partition adaptation: If data is obtained from Security Zone I (such as a power information protection substation), access zone equipment (such as a forward isolation device) must be deployed between the client and the IED to ensure compliance with power safety protection specifications. Performance optimization: If the IED model is large (containing a large number of LN / DO / DAI), it is recommended to obtain the directory in batches to avoid excessive memory consumption in a single traversal; LNs with specific prefixes can be filtered using lnPrefix to reduce the amount of data.

[0061] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0062] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for independent calculation and verification of CRC based on the IEC61850 online model, characterized in that: Includes the following steps: Create an IED connection object on the client and initialize an error container for establishing communication and storing error codes; Establish a communication connection with the IED using the IEC61850MMS protocol. During the connection establishment process, set the IP address and MMS port number of the IED, and confirm whether the communication is successful based on the return value. After the communication connection is established, the IED operation model is parsed layer by layer according to the hierarchical relationship of server, logical node, data object and data attribute, and the logical node directory, data object directory and data attribute directory are obtained in sequence, and the parsing results are stored as a linked list structure. Extract the data attributes obtained from the parsing, including their name, sAddr, and data type. When a data attribute does not have a defined sAddr, fill in a preset placeholder to ensure the integrity of the field, and keep the above information in the form of a linked list. According to the GBT32890-2016 Relay Protection IEC61850 Engineering Application Model Specification, the fields are uniformly encoded, character set consistent, and ordered to form a deterministic data sequence. The first CRC value of the running model is calculated for the data sequence. At the same time, the corresponding SCD configuration file is parsed and a second CRC value is generated according to the same field extraction, unified encoding and sorting rules. The first CRC value and the second CRC value are compared. A hierarchical CRC structure containing data attribute level CRC, data object level CRC, logical node level CRC and device level CRC is constructed based on a hierarchical folding method for difference location. When the first CRC value matches the second CRC value, it confirms that the IED operating model is consistent with the SCD configuration file; when they do not match, the specific logical node, data object or data attribute is located according to the hierarchical CRC structure, and file recall or online reading is triggered only for the located difference branch. The final comparison result, difference location and alarm information are output to the background system for recording and prompting.

2. The CRC independent calculation and verification method based on the IEC61850 online model according to claim 1, characterized in that: Before establishing a communication connection, the client calls an interface function to create an IED connection object and initializes an error handling container, which stores error codes generated during communication.

3. The CRC independent calculation and verification method based on the IEC61850 online model according to claim 2, characterized in that: During the communication establishment process, the client calls the interface function to connect with the IED. When calling the interface function, the client inputs the IP address and MMS port number of the IED and determines whether the connection is established by the return value of the interface function. A return value of zero indicates that the connection is established successfully, and a non-zero return value is stored in the error handling container.

4. The CRC independent calculation and verification method based on the IEC61850 online model according to claim 3, characterized in that: After the communication connection is established, the client sequentially calls the interface function to obtain the logical node directory, data object directory, and data attribute directory. The directory information is organized according to the hierarchical relationship of server, logical node, data object, and data attribute, and stored using a linked list structure.

5. The CRC independent calculation and verification method based on the IEC61850 online model according to claim 4, characterized in that: The parsed data attributes are called via an interface function to obtain the attribute name, sAddr, and data type. When a data attribute does not return sAddr, a preset placeholder is written to replace the field, and the attribute name, sAddr, and data type are stored in a linked list structure.

6. The CRC independent calculation and verification method based on the IEC61850 online model according to claim 5, characterized in that: When extracting data attributes, the client calls an interface function to obtain the name, sAddr, and data type of the data attribute. When the interface function does not return sAddr, a preset placeholder is written to replace the field, and the name, sAddr or the preset placeholder and data type are stored in a linked list structure.

7. The CRC independent calculation and verification method based on the IEC61850 online model according to claim 6, characterized in that: The consistency verification of the operating model includes: calculating a first CRC value for the aforementioned normalized data sequence, parsing the corresponding SCD configuration file and generating a second CRC value according to the same field extraction, unified encoding and sorting rules, comparing the first CRC value with the second CRC value, and constructing a hierarchical CRC structure including data attribute level CRC, data object level CRC, logical node level CRC and device level CRC through a step-by-step folding method, so as to determine the branch where the difference is located when the comparison is inconsistent.

8. The CRC independent calculation and verification method based on the IEC61850 online model according to claim 7, characterized in that: When the first CRC value of the running model is equal to the second CRC value of the SCD configuration file, it is determined that the IED running model is consistent with the SCD configuration file. When the first CRC value is not equal to the second CRC value, the specific logical node, data object or data attribute is located based on the hierarchical CRC structure, and only the located difference branch is subjected to file recall or online reading again. The comparison result and difference branch information are output to the background system for recording.

9. The CRC independent calculation and verification method based on the IEC61850 online model according to claim 7, characterized in that: The extracted attribute names, sAddr, and data types are uniformly encoded according to the GBT32890-2016 Relay Protection IEC61850 Engineering Application Model Specification. The string fields are converted to a unified character set and sorted according to the preset field order and lexicographical order to generate a standardized data sequence for CRC calculation.

10. The CRC independent calculation and verification method based on the IEC61850 online model according to claim 7, characterized in that: After completing directory traversal and data extraction, the linked list release function is called to destroy the linked list used to store the logical node directory, data object directory, and data attribute directory; and the connection closing and destruction function is called to close the communication connection with the IED and destroy the connection object.

Images