Normalization analysis mapping method and system for heterogeneous fire-fighting internet of things terminal communication protocols

Abstract

This invention relates to the field of fire protection IoT communication technology, and discloses a normalized parsing and mapping method and system for heterogeneous fire protection IoT terminal communication protocols. The method parses heterogeneous fire protection original messages hierarchically to obtain a message syntax abstract tree, constructs a fire protection business semantic dictionary to obtain a format decoupling semantic feature set, generates a dynamic matching business mapping topology by combining standardized fire protection data inductive graphs, generates standardized fire protection target messages after anomaly handling and structural constraints, quantifies the mapping confidence based on transmission feedback and updates the fire protection business semantic dictionary in reverse, and can automatically adapt to changes in vendor proprietary protocols to reduce the cost of interfacing and maintaining heterogeneous fire protection IoT.

Description

Technical Field

[0001] This invention relates to the field of fire protection IoT communication technology, and in particular to a normalized parsing mapping method and system for heterogeneous fire protection IoT terminal communication protocols. Background Technology In fire protection IoT systems, there are numerous heterogeneous fire protection terminal devices from different manufacturers. These terminals mostly use custom proprietary communication protocols for data transmission, requiring normalization and parsing of the protocol messages before they can be uniformly accessed and processed by the platform. Existing technologies typically employ a hard mapping method using pre-built feature libraries to achieve normalization and parsing. Based on preset mapping rules, proprietary protocol fields are mapped to unified standardized fields, enabling unified access and management of data from terminals from different manufacturers.

[0002] In practice, during routine maintenance of heterogeneous fire alarm terminals already connected to the platform, after engineers complete the integration of a fire alarm terminal from a certain vendor, the vendor subsequently updates the terminal firmware, making only non-preset format adjustments to the protocol without changing the core business meaning. These adjustments include changing private field names, rearranging some fields, and deleting reserved fields that do not carry core business information. Consequently, the platform cannot parse the correct normalized data. The root cause of this problem is that the existing mapping rules bind the semantic attributes of core fire alarm business fields to message format attributes, relying on format features such as the name and position of message fields to complete the mapping. This only adapts to the protocol format known at the time of integration and lacks a dynamic semantic matching mechanism that incorporates fire alarm business knowledge. Therefore, it cannot automatically identify the core business fields after format adjustments, requiring manual modification of the mapping rules to restore parsing. This issue leads to a continuous increase in the labor costs of routine maintenance after third-party terminal integration. If manual modifications are not timely, parsing interruptions and data loss will continue to occur. In the event of a fire, the platform cannot obtain alarm information reported by the terminal in a timely manner, potentially delaying fire response and increasing the operational risks of fire prevention and control. Summary of the Invention

[0003] To address the above problems, the present invention provides the following technical solution: Normalized parsing mapping method for communication protocols of heterogeneous fire protection IoT terminals: S1: Obtain heterogeneous fire protection raw message data and fire protection standard field table, perform hierarchical parsing on the heterogeneous fire protection raw message data to obtain message syntax abstract tree, construct fire protection business semantic dictionary based on fire protection standard field table, use fire protection business semantic dictionary to perform semantic decoupling calculation on message syntax abstract tree to obtain format decoupling semantic feature set; Further, step S1 includes: S11: Obtain heterogeneous fire protection raw message data through the data endpoint retrieval function of the independent third-party interface module; extract the display description configuration parameters of third-party devices and alarm modules, and merge them to generate a fire protection standard field table; S12: Using non-terminal symbol splitting and key-value pair extraction protocols, the heterogeneous fire protection raw message data is parsed by hierarchical nested traversal, and the data carriers within the hierarchy are parsed into parent-child connection relationships, generating a message syntax abstract tree with depth identifier; S13: Based on the common semantic nouns in the fire protection standard field table and expanding the scope of the thesaurus, and in conjunction with the regular expression configuration engine framework, establish a fire protection business semantic dictionary with attribute judgment identifiers; S14: Based on the fire service semantic dictionary, perform semantic unpacking calculation on the message syntax abstract tree, strip the physical nesting framework and non-business regular tags from the message syntax abstract tree, and separate the output format decoupled semantic feature set that is not limited by position rule dependency; Further, step S14 includes: S141: Traverse the last node in the message syntax abstract tree that carries the specific data payload content, and strip the English name string and the corresponding payload information of each last node; S142: Import the English name string into the fire protection business semantic dictionary, perform classification convergence calculation, and search for the matching to obtain the fire protection core business fractal root with the highest degree of belonging; S143: Identify the numerical memory format category of the corresponding location load information, and then encapsulate and bind the numerical memory format category, fire core business fractal root words and the original business load content in the opposite direction to generate a format decoupling semantic feature set.

[0004] S2: Extract regular nodes within the business architecture to construct a standardized fire data summary map. Based on the standardized fire data summary map and the format decoupling semantic feature set, perform feature correspondence calculations to obtain a node association probability matrix. Generate a dynamic matching business mapping topology based on the node association probability matrix. Further, step S2 includes: S21: Extract physical location attributes and early warning level settings from the building system monitoring dimension and equipment details alarm management module of the fire protection platform as standard entity nodes, establish a tree-shaped hierarchical connection relationship between standard entity nodes, and build a standardized fire protection data summary map. S22: Extract cyclic business feature sub-pieces to be compared in batches from the format decoupled semantic feature set, perform similarity intersection measurement calculation on the cyclic business feature sub-pieces to be compared with each standard entity node contained in the standardized fire data summary map, and obtain the association matching score of pairwise mapping. Further, step S22 includes: S221: Calculate the Levenstein edit distance quantization representation of the fire core business fractal root and the character sequence of the standard entity node name stored in the business feature sub-slice to be compared in the loop, and perform inverse proportional processing on the Levenstein edit distance quantization representation to obtain the character relevance evaluation score. S222: Compare the allowable overlap width of the numerical memory format category and the mandatory input data format of the standard entity node of the business feature sub-piece to be compared in the comparison loop, and evaluate the type matching score based on the allowable overlap width. S223: Combining the set feature operator coefficient weights, the character relevance evaluation score and the type matching judgment score are merged and accumulated, and the total conversion result is confirmed as the association matching score.

[0005] S23: Summarize and record the correlation matching scores between all the business feature sub-pieces to be compared in the loop and the corresponding points of the standardized fire protection data summary map, and implement a matrix cross-arrangement mechanism to form a node correlation probability matrix with row and column mapping correspondence. S24: The global maximum weight matching search optimization algorithm is invoked to explore the feature map connection configuration item combination that breaks through the peak performance of the sum of global association matching scores, based on the node association probability matrix. The dynamic matching business mapping topology with the function of instruction flow layer is established directly based on the selected feature map connection configuration item combination.

[0006] S3: Check the internal connection of the dynamic matching business mapping topology, perform abnormal connection elimination and structural constraint processing, output the optimal normalized mapping path set, and perform data node reconstruction and transformation operations on the message syntax abstract tree based on the optimal normalized mapping path set to generate standardized fire target messages. Further, step S3 includes: S31: Examine the one-to-many mapping conflicting branch lines in the dynamic matching business mapping topology, and perform funnel verification and default value placeholder according to the target forced header filling rule instruction to filter and obtain the optimal normalized mapping path set with continuous structure; Further, step S31 includes: S311: Scan full traversal dynamic matching business mapping topology query concurrent bifurcation pointing to cluster in single-point burst divergence state; S312: For concurrent bifurcation pointing clusters, abnormal connection elimination operation is carried out to investigate and process the problem. In the multiple pointing connections, the inferior mapping branches with low score values ​​are eliminated, and the single connection trunk with the highest extreme value is exclusively retained. S313: Introduce the mandatory component filling requirement clause in the platform's general alarm form to verify and validate the graph remnants after the execution of abnormal connection removal operations. For cases where critical paths are missing, implement the underlying placeholder to fill in the execution structural constraint processing steps, and obtain the optimal normalized mapping path set through correction.

[0007] S32: Read the message syntax abstract tree retained by the original temporary storage system, strictly compare it with the rewrite, replacement and transfer rule instructions formulated by the optimal normalized mapping path set, rewrite and reorganize each node of the message syntax abstract tree and mount it into the exact category-level tree structure clearly indicated by the fire platform definition specification, and create a serialized precursor for obtaining the target tree level. S33: The text format splicing and parsing suite in the backend of the activation component initiates the sequential structure transcribing, packaging and encapsulation process of the target tree hierarchical serialization precursor, generating a standardized fire target message that conforms to the general text exchange protocol standard.

[0008] S4: Utilize the platform's lower-level message template push channel to transmit standardized fire target messages and obtain platform interface call feedback records. Based on the platform interface call feedback records, quantify and parse the mapping confidence evaluation value. Based on the mapping confidence evaluation value, perform experience-based solidification and reverse update of the fire business semantic dictionary. Further, step S4 includes: S41: By leveraging the platform's built-in alarm notification message push channel, standardized fire target messages are presented to the third-party dashboard, and the front end performs transmission, distribution, display, and handover actions. During the transmission and distribution process, the bypass asynchronous communication monitoring and recording probe is activated. S42: Command bypass asynchronous communication monitoring and recording probe monitors and tracks the entire process of standardized fire target messages entering the target database table for rendering and presentation. It collects and packages the deep prompt response signal segments dispatched when the page loads or is fully filled, and provides platform interface call feedback records accordingly. S43: Extract the statistical data of the number of error interruption blocking and alarm triggers and the Boolean flag of successful front-end rendering from the platform interface call feedback records. Use the system multi-source reliability prediction and evaluation equation to perform weighted and combined calculations on the two, thereby outputting a mapping confidence evaluation value that represents the strength of the current automation rule establishment reliability and effectiveness performance scale. S44: Utilize the decision-judgment logic structure to verify whether the mapping confidence evaluation value can successfully exceed the experience self-coverage replacement boundary threshold. If the judgment conditions are fully met, it means that the adaptation to the new flexible format operation is successful. Then, directly extract the one-to-one unknown attribute name association equation derived from the optimal normalized mapping path set to complete the input of the lagging fire business semantic dictionary, thereby realizing the automatic variation of heterogeneous fields following the normal evolution operation mechanism.

[0009] A normalized parsing and mapping system for heterogeneous fire protection IoT terminal communication protocols is provided to implement the aforementioned normalized parsing and mapping method for heterogeneous fire protection IoT terminal communication protocols. The system includes: a semantic decoupling module, used to acquire heterogeneous original fire protection message data and a fire protection standard field table; perform hierarchical parsing on the heterogeneous original fire protection message data to obtain a message syntax abstract tree; construct a fire protection business semantic dictionary based on the fire protection standard field table; and perform semantic decoupling calculation on the message syntax abstract tree using the fire protection business semantic dictionary to obtain a format decoupling semantic feature set; and a mapping topology generation module, used to extract regular nodes within the business architecture to construct a standardized fire protection data summarization graph; and perform feature correspondence calculation based on the standardized fire protection data summarization graph and the format decoupling semantic feature set. The system calculates a node association probability matrix and generates a dynamic matching business mapping topology based on this matrix. A standardized message generation module checks the internal connections of the dynamic matching business mapping topology, removes abnormal connections, and handles structural constraints. It outputs an optimized normalized mapping path set and performs data node reconstruction and transformation operations on the message syntax abstract tree based on this set to generate a standardized fire protection target message. A feedback update module uses the platform's lower-level message template push channel to transmit the standardized fire protection target message, obtains platform interface call feedback records, quantifies and parses the mapping confidence evaluation value according to the platform interface call feedback records, and performs an experience-based reverse update of the fire protection business semantic dictionary based on the mapping confidence evaluation value.

[0010] Compared to existing technologies, the advantages of this invention are as follows: This invention addresses the problem of inconsistent proprietary protocol formats among different manufacturers of heterogeneous fire protection IoT terminals. Traditional normalization schemes rely on precise matching of field names and positions, and the mapping rules become invalid after manufacturers adjust their protocols, requiring manual modification of adaptation rules. This invention obtains a message syntax abstract tree through hierarchical parsing of heterogeneous fire protection original messages. Combined with a fire protection business semantic dictionary constructed based on extended synonyms of fire protection standard fields, semantic unpacking calculation is performed to obtain a format-decoupled semantic feature set that does not depend on message nesting positions and original formats. This set can tolerate manufacturer field renaming and nesting level adjustments, eliminating the format dependency problem of traditional solutions. This invention calculates the association matching score through a dual-dimensional approach of semantic similarity and data type compatibility, and uses a global optimization algorithm to obtain a dynamic matching business mapping topology. This ensures the accuracy of semantic matching and eliminates incorrect mappings through type constraints, avoiding the local optimum problem caused by greedy matching. This invention resolves mapping conflicts by eliminating abnormal connections and filling missing fields with default placeholder values, ensuring the integrity of the standardized message structure and preventing platform parsing errors caused by missing fields. It also establishes an adaptive update mechanism for the fire service semantic dictionary based on actual operational feedback, enabling automatic adaptation to vendor protocol evolution and significantly reducing daily maintenance costs. This invention belongs to the field of electronic digital data processing and effectively improves the reliability and automation level of heterogeneous fire communication protocol parsing and processing. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a flowchart of the normalized parsing mapping method for the communication protocol of heterogeneous fire protection IoT terminals in this invention; Figure 2 This is a schematic diagram illustrating the generation of a message syntax abstraction tree through hierarchical parsing in an embodiment of the present invention; Figure 3 A schematic diagram illustrating the construction of a fire service semantic dictionary in an embodiment of the present invention; Figure 4 This is a schematic diagram illustrating the semantic decoupling semantic feature set obtained by semantic unpacking calculation in an embodiment of the present invention; Figure 5 This is a schematic diagram of a standardized fire protection data summary map in an embodiment of the present invention; Figure 6 This is a schematic diagram illustrating feature correspondence calculation and Hungarian algorithm matching in an embodiment of the present invention; Figure 7This is a schematic diagram illustrating the abnormal connection removal and default value filling in an embodiment of the present invention; Figure 8 This is a schematic diagram illustrating the generation of standardized target messages through data node reconstruction in an embodiment of the present invention; Figure 9 This is a schematic diagram of feedback-driven reverse update of the fire service semantic dictionary in an embodiment of the present invention; Figure 10 This is a functional block diagram of the normalized parsing mapping system for the heterogeneous fire protection IoT terminal communication protocol in this invention. Detailed Implementation

[0013] 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.

[0014] Example 1: Please see Figure 1 As shown, this embodiment provides a normalized parsing mapping method for heterogeneous fire protection IoT terminal communication protocols, including: S1: Obtain heterogeneous fire protection raw message data and fire protection standard field table, perform hierarchical parsing on the heterogeneous fire protection raw message data to obtain message syntax abstract tree, construct fire protection business semantic dictionary based on fire protection standard field table, use fire protection business semantic dictionary to perform semantic decoupling calculation on message syntax abstract tree to obtain format decoupling semantic feature set; Further, step S1 includes the following steps: S11: Obtain heterogeneous fire protection raw message data through the data endpoint retrieval function of the independent third-party interface module; extract the display description configuration parameters of third-party devices and alarm modules, and merge them to generate a fire protection standard field table; Further, step S11 includes the following steps: S111: Through the independent third-party interface module built into the fire protection integrated management platform, the pre-configured data endpoint retrieval function in the independent third-party interface module is invoked to initiate a data retrieval request to a third-party fire protection IoT platform that has completed standardized interface parameter configuration. The independent third-party interface module is a functional module within the fire protection integrated management platform specifically responsible for data interaction with external heterogeneous devices and platforms. The independent third-party interface module pre-stores access parameters for each third-party platform, including interface address, account, password, application key, and access token. The data endpoint retrieval function refers to the function of the independent third-party interface module initiating a data acquisition request to the third-party fire protection IoT platform and receiving return messages according to the pre-configured interface address and authentication parameters, either through periodic polling or event triggering. The heterogeneous fire protection raw message data refers to the raw communication messages returned from fire protection IoT platforms of different manufacturers that have not undergone any format conversion. The data format of the heterogeneous fire protection raw message data is a text stream in string form, and the heterogeneous fire protection raw message data contains field names, nested hierarchical structures, and business data payloads privately defined by each manufacturer. For example, when the fire protection management platform initiates a data retrieval request to the Dahua platform, the independent third-party interface module uses the access token corresponding to the Dahua platform as authentication credentials and sends a request to the pre-configured interface address of the Dahua platform. The Dahua platform returns raw messages containing information such as alarm events and equipment failures. When the fire protection management platform initiates a data retrieval request to the Sixin platform, the independent third-party interface module uses the username and password corresponding to the Sixin platform as authentication credentials and sends a request to the pre-configured interface address of the Sixin platform. The Sixin platform returns raw messages containing information such as low battery alarms and smoke detector alarms. The heterogeneous fire protection raw message data returned by different manufacturers exhibits significant differences in field naming methods, nesting depth, and data encoding rules.

[0015] S112: Extract equipment display description configuration parameters from the equipment management module of the fire protection integrated management platform, and extract alarm display description configuration parameters from the alarm management module of the fire protection integrated management platform. Merge the equipment display description configuration parameters and alarm display description configuration parameters to generate a fire protection standard field table. The equipment display description configuration parameters refer to the standardized set of fields uniformly defined by the fire protection integrated management platform for all fire protection equipment in the equipment management module. These parameters include equipment number, equipment name, equipment type, installation location, affiliated unit, equipment status, and most recent online time. The alarm display description configuration parameters refer to the standardized set of fields uniformly defined by the fire protection integrated management platform for all alarm events in the alarm management module. These parameters include alarm unit, alarm equipment, equipment number, alarm time, alarm description, alarm count, notification method, and processing status. The data structure of the fire protection standard field table is a two-dimensional table structure. Each row of the fire protection standard field table contains four column attributes: field standard name, field data type, field business category, and whether the field is mandatory. The data types of the fields include string, integer, floating-point, timestamp, and boolean. The business categories to which the fields belong include equipment information, alarm information, location information, and status information. For example, a record in the fire protection standard field table has a field standard name of "device_code", a data type of "string", a business category of "equipment information", and a mandatory field flag of "yes".

[0016] S12: Using non-terminal symbol splitting and key-value pair extraction protocols, the heterogeneous fire protection raw message data is parsed by hierarchical nested traversal, and the data carriers within the hierarchy are parsed into parent-child connection relationships, generating a message syntax abstract tree with depth identifier; Further, step S12 includes the following steps: S121: Perform non-terminal symbol splitting on heterogeneous fire protection raw message data. The non-terminal symbol splitting operation refers to the process of using structural delimiters in the message format as splitting markers to decompose the heterogeneous fire protection raw message data layer by layer into nested substructures. The structural delimiters have different forms in different message formats: when the format of the heterogeneous fire protection raw message data is a key-value pair nested format, the structural delimiters include left curly braces, right curly braces, left square brackets, and right square brackets; when the format of the heterogeneous fire protection raw message data is a tag nested format, the structural delimiters include left angle brackets and right angle brackets. Starting from the outermost structural delimiter of the heterogeneous fire protection raw message data, identify and split each layer of nested substructures layer by layer inwards, recording the nesting depth value of each nested substructure relative to the outermost layer. The nesting depth value is a non-negative integer starting from 0, with the outermost nesting depth value being 0. The nesting depth value increases by 1 for each layer nested inwards. All the split nested substructures and their corresponding nesting depth values ​​are combined into a hierarchical splitting result set.

[0017] S122: Perform a key-value pair extraction operation on each nested substructure in the hierarchical splitting result set. The key-value pair extraction operation refers to the process of identifying and extracting the corresponding binding relationships between field names and field values ​​from the nested substructures. In the nested key-value pair format, field names and field values ​​are separated by a colon; in the tag nested format, field names are represented by tag names, and field values ​​are represented by the content enclosed in the tag. For each nested substructure, extract all field names and corresponding field values ​​contained in the nested substructure to form a key-value pair list. When a field value itself is a nested substructure, the field value is marked as a non-leaf node; when a field value is basic data that cannot be further divided, the field value is marked as a leaf node.

[0018] S123: Construct parent-child connection relationships based on the hierarchical splitting result set and the key-value pair list. Set the outermost structure of the heterogeneous fire-fighting raw message data as the root node, with a nesting depth of 0. For nested substructures with a nesting depth of n in the hierarchical splitting result set, set the field name corresponding to the nested substructure as the child node, and set the field name corresponding to the nested substructure with a nesting depth of n-1 above the nested substructure as the parent node. Establish directed edges from the parent node to the child node, forming parent-child connection relationships. Traverse all nested substructures in the hierarchical splitting result set, and assemble all parent-child connection relationships into a message syntax abstract tree with depth identifiers.

[0019] See Figure 2 This is a schematic diagram of the hierarchical parsing and generation of message syntax abstraction tree provided in the embodiments of this application. For example... Figure 2As shown in the diagram, this visually illustrates the hierarchical parsing process of heterogeneous messages, transforming them from raw linear strings into a multi-way tree structure. In fire protection IoT scenarios, the nesting levels and delimiters (such as the key-value pair nesting format and tag nesting format shown on the left) of the status and alarm information reported by different equipment manufacturers vary greatly. Through actions such as "non-terminal symbol splitting" and "key-value pair extraction" in the middle of the diagram, the complex source messages are transformed into a unified multi-way tree structure (i.e., a message syntax abstract tree) with depth identifiers and node labels on the right. This parsing process abstracts the lineage relationships between leaf and non-leaf nodes at each level, shielding the apparent differences in physical format and hierarchical depth between different manufacturers' proprietary protocols. This provides a systematic and standardly traversable data structure foundation for subsequent separation and peeling steps, allowing the relationships of multi-level nested data to be intuitively placed within a unified system.

[0020] S13: Based on the common semantic nouns in the fire protection standard field table and expanding the scope of the thesaurus, and in conjunction with the regular expression configuration engine framework, establish a fire protection business semantic dictionary with attribute judgment identifiers; Furthermore, step S13 includes the following steps: S131: Extract the standard name of each field from the fire protection standard field table row by row. Perform camelCase and underscore segmentation on each field standard name to decompose it into a basic semantic word sequence. CamelCase segmentation refers to segmenting at the boundary between uppercase and lowercase letters in the field standard name. Underscore segmentation refers to segmenting at the positions where underscores appear in the field standard name. For example, the field standard name "deviceCode" after camelCase segmentation yields the basic semantic word sequence "device" and "code"; the field standard name "alarm_time" after underscore segmentation yields the basic semantic word sequence "alarm" and "time". Summarize and deduplicate the basic semantic word sequences corresponding to all field standard names to obtain a set of general semantic words for the fire protection field.

[0021] S132: For each semantic term in the general semantic term set for the fire protection field, query the pre-set fire protection field synonym mapping table to expand and obtain the synonym list corresponding to each semantic term. The fire protection field synonym mapping table is a pre-compiled mapping table based on commonly used terminology in the fire protection industry and the naming conventions of equipment manufacturers. The data structure of the fire protection field synonym mapping table is a set of key-value pairs, where the key is the standard semantic term and the value is the synonym list. For example, the synonym list corresponding to the standard semantic term "device" includes "dev", "equipment", "sensor", and "detector"; the synonym list corresponding to the standard semantic term "alarm" includes "alert", "warning", and "fault"; and the synonym list corresponding to the standard semantic term "location" includes "loc", "position", "addr", and "place". Merge each semantic term and its synonym list to form an expanded semantic term set.

[0022] S133: For each extended semantic tuple in the extended semantic tuple set, generate a corresponding regular expression matching pattern using a regular expression configuration engine framework. The regular expression configuration engine framework refers to an automated generation framework that, based on regular expression syntax rules, concatenates all the lexical units in the extended semantic tuple using an "OR" relationship to assemble a regular expression matching rule. For example, the regular expression matching pattern generated for the extended semantic tuple "device,dev,equipment,sensor,detector" is "(device|dev|equipment|sensor|detector)", which can match any input string containing one of the aforementioned lexical units.

[0023] S134: Assemble each extended semantic tuple, its corresponding regular expression matching pattern, and the corresponding field data type and business category in the fire protection standard field table into a dictionary record, and attach an attribute determination identifier to each dictionary record. The attribute determination identifier is a binary tag value, taking the values ​​of "core business attribute" or "auxiliary description attribute". The determination method for the attribute determination identifier is as follows: read whether the field corresponding to the current dictionary record is a mandatory field from the fire protection standard field table. If the value of the mandatory field ...

[0024] See Figure 3 This is a schematic diagram illustrating the construction of a fire protection business semantic dictionary provided in an embodiment of this application. For example... Figure 3 As shown in the diagram, this illustrates the processing logic for transitioning from static standard fields to dynamic business parsing vocabulary. The left side of the diagram reflects the standard field dimensional constraints of the native system. The middle section uses operators such as "binary core attribute determination," "multi-modal dimensionality reduction structure splitting," and "retrieving and loading an external pre-defined thesaurus," ultimately generating a business dictionary storage list on the right containing dynamic matching patterns built from regular expressions. In heterogeneous monitoring scenarios, various system field names are prone to containing unrecorded abbreviations and combinations. This dynamic semantic generation construction flow, which departs from single-point-to-point hardcoding, significantly increases the tolerance of the main control platform in recognizing unfamiliar letter combinations. This provides the entire semantic matching mechanism with robust generalization capabilities, ensuring that core business attributes are effectively extracted and classified from complex heterogeneous tags.

[0025] S14: Based on the fire service semantic dictionary, perform semantic unpacking calculation on the message syntax abstract tree, strip the physical nesting framework and non-business regular tags from the message syntax abstract tree, and separate the output format decoupled semantic feature set that is not limited by position rule dependency; Furthermore, step S14 includes the following steps: S141: Traverse all terminal nodes in the message syntax abstract tree whose node type is marked as a leaf node. Extract the node name from each terminal node as an English name string, and extract the node payload value as the corresponding position payload information. The English name string is the character sequence of the original field name stored in the terminal node. The corresponding position payload information is the original business data content stored in the terminal node.

[0026] S142: Import the English name string of each terminal node into the fire protection business semantic dictionary and perform classification convergence calculation. The execution process of the classification convergence calculation is as follows: Perform regular expression matching operation on the English name string using the regular expression matching pattern of each dictionary record in the fire protection business semantic dictionary. When the English name string successfully matches the regular expression matching pattern of a certain dictionary record, calculate the ratio of the number of matched characters to the total number of characters in the English name string, and record this ratio as the affiliation score. When the English name string successfully matches the regular expression matching patterns of multiple dictionary records, select the dictionary record with the highest affiliation score as the best matching dictionary record. Extract the business category to which the field belongs from the best matching dictionary record, and determine the business category to which the field belongs as the fire protection core business fractal root corresponding to the current English name string. The fire protection core business fractal root refers to the business category identifier to which the current English name string belongs under the fire protection business semantic system. When the English name string fails to match the regular expression matching patterns of all dictionary records in the fire protection business semantic dictionary, mark the fire protection core business fractal root corresponding to the current English name string as "unidentified category". For example, suppose the English name string of a certain terminal node is "devId", and there is a dictionary record in the fire service semantic dictionary with the regular expression matching pattern "(device|dev|equipment|sensor|detector)". This regular expression matching pattern successfully matches the "dev" part of "devId", with a matched character count of 3. The total number of characters in the English name string "devId" is 5, and the belongingness score is . Meanwhile, assuming that the regular expression matching pattern of another dictionary record in the fire service semantic dictionary is "(id|identifier|code|number)", and that this regular expression matching pattern successfully matches the "Id" part of "devId", the attribution score is... Since 0.6 is greater than 0.4, the dictionary record with a membership score of 0.6 is selected as the best matching dictionary record. The business category to which the field belongs is extracted from the best matching dictionary record and identified as "equipment information". "Equipment information" is determined as the fire protection core business fractal root corresponding to the English name string "devId".

[0027] S143: Identify the numerical memory format category of the corresponding positional load information for each terminal node. The identification method for the numerical memory format category is as follows: For the corresponding positional load information, perform integer format determination, floating-point number format determination, timestamp format determination, and Boolean format determination sequentially. When the corresponding positional load information can be successfully parsed as an integer, the numerical memory format category is determined to be an integer type; when the corresponding positional load information can be successfully parsed as a floating-point number, the numerical memory format category is determined to be a floating-point number type; when the corresponding positional load information conforms to a preset timestamp regular expression matching pattern, the numerical memory format category is determined to be a timestamp type. The preset timestamp regular expression matching pattern is written based on common time formats, including year-month-day-hour-minute-second format and timestamp numerical format; when the value of the corresponding positional load information is "true" or "false", the numerical memory format category is determined to be a Boolean type; when the corresponding positional load information does not conform to any of the above format determination conditions, the numerical memory format category is determined to be a string type. The numerical memory format category of each terminal node, the fire protection core business multidimensional root, and the corresponding positional load information are encapsulated into a semantic feature record. The semantic feature record data structure is a triple. The first element of the triple is the numerical memory format category, the second element is the fire protection core business fractal root, and the third element is the original content of the load information at the corresponding location. All semantic feature records corresponding to the last node are aggregated to form a format-decoupled semantic feature set.

[0028] See Figure 4 This is a schematic diagram illustrating the semantic decoupling semantic feature set obtained through semantic unpacking calculation provided in this application embodiment. For example... Figure 4 As shown, the diagram clearly illustrates how the message syntax abstraction tree evolves from physically nested rules to discrete, purely semantic features. The middle section of the diagram demonstrates how, after extracting the terminal nodes from the tree structure, the left side categorizes "firefighting core business fractal roots" through name expansion mapping, the right side identifies and defines "numerical memory format categories" through algorithms, and the bottom section synthesizes card-style multidimensional blocks. Each individual "feature record unit" at the bottom of the diagram has completely broken free from all original message nesting or arrangemental constraints. This stage dismantles the spatial constraints imposed by different terminals, completely breaking down the previously interwoven business content into easily aligned triplet arrays, ensuring that subsequent feature units can perform cross-boundary aggregation operations without positional interference based on pure category attributes and format dimensions, in accordance with standardization requirements.

[0029] Specifically, step S1 achieves the goal of decoupling and separating the core business fields in the proprietary protocol messages of different vendors from the message format framework through three stages of processing: hierarchical parsing, semantic dictionary construction, and semantic unpacking calculation. In actual deployment scenarios of fire protection IoT, different vendors' fire protection equipment and platforms often adopt their own independent naming habits and nested structures when defining communication messages. Taking Dahua platform and Sixin platform as examples, to represent the business concept of "device number", Dahua platform may use "deviceCode" as the field name and place the field in the first-level nested structure of the message, while Sixin platform may use "devId" as the field name and place the field inside the "alarmInfo" substructure of the second-level nested structure of the message. Traditional normalized parsing schemes rely on precise matching of field names and field positions to complete the mapping. When vendors rename fields or adjust the nesting level of proprietary protocols, the mapping rules of traditional schemes become invalid, and engineers must manually modify the adaptation rules. The semantic de-packaging calculation in step S14 utilizes a classification convergence mechanism based on synonym expansion and regular expression matching in the fire service semantic dictionary to transform field names from literal forms into business category attributions. This ensures that regardless of whether the vendor renames "deviceCode" to "devId" or "equipmentNo," as long as the field name contains semantic elements covered by the fire service semantic dictionary, it can be correctly classified into the same core fire service fractal root. Simultaneously, the semantic de-packaging calculation extracts field values ​​from their physical nesting positions in the message syntax abstract tree. This ensures that each semantic feature record in the format decoupling semantic feature set no longer carries any positional dependency information. Regardless of how the vendor adjusts the nesting position and arrangement order of fields in the message, the content of the format decoupling semantic feature set remains stable. The message syntax abstract tree constructed in step S12 provides a structured traversal foundation for the semantic de-packaging calculation in step S14. Without the hierarchical parsing in step S12, step S14 would be unable to systematically locate all terminal nodes and extract the English name strings and corresponding positional payload information. The fire service semantic dictionary constructed in step S13 provides a matching basis for the classification convergence calculation in step S14. Without the synonym expansion and regular expression matching pattern generation in step S13, step S14 would degenerate into simple string exact matching, unable to handle field renaming adjustments by vendors. The format decoupling semantic feature set output in step S1 provides pure business semantic input independent of message format for the feature correspondence calculation in the subsequent step S2, serving as the prerequisite data foundation for realizing dynamic matching business mapping topology construction.

[0030] S2: Extract regular nodes within the business architecture to construct a standardized fire data summary map. Based on the standardized fire data summary map and the format decoupling semantic feature set, perform feature correspondence calculations to obtain a node association probability matrix. Generate a dynamic matching business mapping topology based on the node association probability matrix. Further, step S2 includes the following steps: S21: Extract physical location attributes and early warning level settings from the building system monitoring dimension and equipment details alarm management module of the fire protection platform as standard entity nodes, establish a tree-shaped hierarchical connection relationship between standard entity nodes, and build a standardized fire protection data summary map. Specifically, the monitoring center name, building name, and network unit name are extracted from the organization management module of the fire protection integrated management platform as standard entity nodes at the physical location attribute level; the equipment number, equipment name, equipment type, installation location, affiliated unit, equipment status, and most recent online time are extracted from the equipment management module of the fire protection integrated management platform as standard entity nodes at the equipment information level; the alarm unit, alarm equipment, alarm number, alarm time, alarm description, alarm frequency, notification method, and processing status are extracted from the alarm management module of the fire protection integrated management platform as standard entity nodes at the alarm information level; and the warning level setting is extracted from the alarm management module of the fire protection integrated management platform as a standard entity node at the warning level level, where the warning level setting includes false alarm, test, follow-up, real fire, and real warning. Each standard entity node contains three attributes: node name, mandatory input data format, and node level. The mandatory input data format for nodes refers to the data type constraints that the fire protection integrated management platform requires current standard entity nodes to accept. The value range of the mandatory input data format is consistent with the data types of the fields in the fire protection standard field table, including string, integer, floating-point, timestamp, and boolean types. A tree-like hierarchical relationship is established between standard entity nodes: the monitoring center name is set as the root-level node, the building name and network unit name are set as child nodes of the root-level node, each standard entity node at the equipment information level is set as a child node of the network unit name node, each standard entity node at the alarm information level is set as a child node of the equipment number node in the equipment information level, and each standard entity node at the warning level is set as a child node of the processing status node in the alarm information level. All standard entity nodes and the tree-like hierarchical relationship are aggregated and assembled into a standardized fire protection data summary diagram.

[0031] See Figure 5 This is a schematic diagram of a standardized fire protection data summary map provided in an embodiment of this application. Through this... Figure 5This diagram presents a templated tree diagram summarizing the data standardization requirements of the receiving system. The entire diagram uses physical location attributes, device status data, and multi-level alarm requirements as its framework, organizing a connected system with clear hierarchical and subordinate relationships. Standard entity nodes attached to lower-level branches within the diagram indicate the mandatory input type constraint verification for the current corresponding item. For complex, multi-source IoT communications, establishing such a standard mapping framework in advance is particularly crucial. It is not used for actual structured storage but specifically serves as the limiting framework for message reconstruction verification. It not only specifies which specific standardized storage structures must accommodate all randomly generated source data hashes but also defines clear system boundaries and data mapping constraints for subsequent multi-point binary search optimization.

[0032] S22: Extract cyclic business feature sub-pieces to be compared in batches from the format decoupled semantic feature set, perform similarity intersection measurement calculation on the cyclic business feature sub-pieces to be compared with each standard entity node contained in the standardized fire data summary map, and obtain the association matching score of pairwise mapping. Specifically, semantic feature records are extracted one by one from the format decoupling semantic feature set output in step S14, and each semantic feature record is used as a cyclic comparison business feature sub-piece. The cyclic comparison business feature sub-piece contains three attributes: numerical memory format category, fire core business fractal root, and original content of corresponding location load information. For each cyclic comparison business feature sub-piece, all standard entity nodes in the standardized fire data summarization graph are traversed, and the similarity intersection metric is calculated between the currently traversed cyclic comparison business feature sub-piece and the currently traversed standard entity node to obtain the association matching score.

[0033] Further, step S22 includes the following steps: S221: Calculate the Levinstein edit distance quantization representation between the core fire protection business fractal terminology stored within the currently traversed loop-to-be-compared business feature sub-slice and the node name of the currently traversed standard entity node. The Levinstein edit distance quantization representation refers to the minimum number of single-character edit operations required to convert the character sequence of the core fire protection business fractal terminology into the character sequence of the node name of the standard entity node. These single-character edit operations include inserting a character, deleting a character, and replacing a character. Perform an inverse proportional processing on the Levinstein edit distance quantization representation to obtain a character relevance evaluation score. The inverse proportional processing is calculated as follows: the character relevance evaluation score equals 1 minus the larger of the Levinstein edit distance quantization representation divided by the length of the character sequence of the core fire protection business fractal terminology and the length of the character sequence of the node name of the standard entity node. For example, assuming the core business term for fire protection is "equipment information category", the node name of the standard entity node is "equipment number", the character sequence length of the core business term is 5, the character sequence length of the node name of the standard entity node is 4, and the Levenstein edit distance between them is 3, then the character relevance evaluation score is: .

[0034] S222: Compare the allowable overlap width between the numerical memory format category of the currently traversed loop's business feature sub-fragments and the mandatory input data format of the currently traversed standard entity nodes. The evaluation method for the allowable overlap width is as follows: when the numerical memory format category and the mandatory input data format are completely identical, the allowable overlap width is 1.0; when there is a lossless conversion relationship between the numerical memory format category and the mandatory input data format, the allowable overlap width is 0.7. The lossless conversion relationship refers to type conversion relationships that do not lose data precision, such as lossless conversion of integer types to floating-point types or lossless conversion of integer types to string types; when the numerical memory format category and the mandatory input data format are neither completely identical nor have a lossless conversion relationship, the allowable overlap width is 0. A type fit score is obtained based on the allowable overlap width evaluation, and the value of the type fit score is equal to the value of the allowable overlap width.

[0035] S223: Combining the set feature operator coefficient weights, a merged accumulation process is performed on the character relevance evaluation score and the type fit judgment score. The total conversion result of the merged accumulation process is confirmed as the association matching score. The calculation method for the merged accumulation process is: the association matching score equals the first feature operator coefficient weight multiplied by the character relevance evaluation score plus the second feature operator coefficient weight multiplied by the type fit judgment score. The method for determining the first feature operator coefficient weight and the second feature operator coefficient weight is: based on the actual need for semantic matching to take precedence over type matching in fire protection business scenarios, the first feature operator coefficient weight is set to be greater than the second feature operator coefficient weight, and the sum of the two is equal to 1. For example, the first feature operator coefficient weight can be set to 0.65, and the second feature operator coefficient weight can be set to 0.35. Continuing the above example, assuming the character relevance evaluation score is 0.4 and the type fit judgment score is 1.0, then the association matching score is... .

[0036] S23: Summarize and record the correlation matching scores between all the business feature sub-pieces to be compared in the loop and the corresponding points of the standardized fire protection data summary map, and implement a matrix cross-arrangement mechanism to form a node correlation probability matrix with row and column mapping correspondence. Specifically, let P be the total number of semantic feature records contained in the format decoupling semantic feature set, and R be the total number of standard entity nodes contained in the standardized fire protection data summary map. Then, a two-dimensional matrix of P rows and R columns is constructed. The element value of the i-th row and j-th column of the two-dimensional matrix is ​​the association matching score between the i-th cyclic business feature sub-slice to be compared and the j-th standard entity node, where i ranges from 1 to P, and j ranges from 1 to R. The two-dimensional matrix is ​​defined as the node association probability matrix. The data structure of the node association probability matrix is ​​a floating-point matrix of P rows and R columns, where each element in the matrix takes a value in a closed interval from 0 to 1.

[0037] S24: The global maximum weight matching search optimization algorithm is called to explore the feature map connection configuration item combination that breaks through the peak performance of the sum of global association matching scores, and the dynamic matching business mapping topology with the function of instruction flow layer is directly established based on the selected feature map connection configuration item combination. Specifically, the global maximum weight matching search optimization algorithm employs the Hungarian algorithm. The Hungarian algorithm is a combinatorial optimization algorithm for solving the maximum weight matching problem in a bipartite graph. The input of the Hungarian algorithm is a node association probability matrix, and the output is a set of row and column pairs that maximize the sum of the selected matrix elements. The P cyclic business feature sub-pieces to be compared in the node association probability matrix are considered as the set of left nodes in the bipartite graph, and the R standard entity nodes are considered as the set of right nodes. Each element in the node association probability matrix is ​​considered as the weight of the connection edge between the left and right nodes. Under the constraint that each left node matches at most one right node and each right node matches at most one left node, the Hungarian algorithm searches for a matching scheme that maximizes the sum of the weights of all selected connection edges. Each pair of selected left and right nodes in the matching scheme output by the Hungarian algorithm is defined as a feature graph connection configuration item. All feature graph connection configuration items are aggregated into a feature graph connection configuration item combination. A dynamic matching business mapping topology is constructed based on the feature graph connection configuration item combination.

[0038] See Figure 6 This is a schematic diagram illustrating the feature correspondence calculation and Hungarian algorithm matching provided in an embodiment of this application. Figure 6 As shown, this diagram illustrates the mechanism for finding the overall optimal allocation mapping scheme between discretized business feature pieces and ordered standard entity nodes. The center of the diagram, within a grid matrix system composed of Levenstein's edit distance correlation assessment and data type conversion tolerance, displays the probabilistic correlations derived from cross-operations. The highlighted sections represent the loop-free optimal connection routes found using the Hungarian decision strategy to prevent cross-interference. In complex data environments with concurrent alarms from multiple devices and high-density similar identifier names, the conventional single-point priority probing logic easily falls into a situation where similar high-molecular items deadlock each other, leading to weakly connected nodes having nowhere to belong and resulting in errors and discarding. The method shown in this diagram successfully avoids local optima by comprehensively managing the configuration of all probabilities, maximizing the stability and efficiency of the system's global mapping.

[0039] Specifically, step S2 achieves the goal of establishing a dynamic mapping relationship between the various business semantic features in the format-decoupled semantic feature set and the standardized field system of the fire protection platform by constructing a standardized fire protection data summary map and performing a two-dimensional feature correspondence calculation based on semantic similarity and type compatibility. In the scenario of heterogeneous device docking in the fire protection IoT, the message fields of different manufacturers not only have different names, but the data types carried by the fields may also differ. Simply relying on character name matching can easily lead to mismapping. Step S221 introduces Levenstein edit distance to measure semantic similarity at the character level, which can tolerate spelling variations and abbreviation differences in field naming by manufacturers; step S222 introduces data type compatibility verification, which can eliminate erroneous mapping candidates with similar character names but incompatible data types. The scores of the two dimensions are weighted and merged to form a comprehensive association matching score, which not only ensures the accuracy of semantic matching, but also increases the reliability of the mapping results through type constraints. Step S24 uses the Hungarian algorithm to solve for the global optimal match, ensuring that the scheme with the largest sum of global association matching scores is selected among all possible mapping combinations, avoiding the local optimum trap that may be caused by greedy matching line by line. The dynamic matching business mapping topology output in step S2 provides an initial mapping scheme for the abnormal connection elimination and structural constraint processing in the subsequent step S3, and is a key intermediate product for achieving the final normalized mapping. If the feature correspondence calculation in step S2 is missing, step S3 will not be able to obtain the mapping topology structure to be optimized, and the entire normalization parsing process will be interrupted.

[0040] S3: Check the internal connection of the dynamic matching business mapping topology, perform abnormal connection elimination and structural constraint processing, output the optimal normalized mapping path set, and perform data node reconstruction and transformation operations on the message syntax abstract tree based on the optimal normalized mapping path set to generate standardized fire target messages. Furthermore, step S3 includes the following steps: S31: Examine the one-to-many mapping conflicting branch lines in the dynamic matching business mapping topology, and perform funnel verification and default value placeholder according to the target forced header filling rule instruction to filter and obtain the optimal normalized mapping path set with continuous structure; Further, step S31 includes the following steps: S311: Scan and traverse all directed edges in the dynamic matching business mapping topology, querying whether there are concurrent bifurcation clusters where the same cyclic matching business feature sub-piece simultaneously points to multiple standard entity nodes, or convergence conflict clusters where the same standard entity node is simultaneously pointed to by multiple cyclic matching business feature sub-pieces. The concurrent bifurcation cluster refers to a set of edges consisting of multiple directed edges originating from the same left-hand node. The convergence conflict cluster refers to a set of edges consisting of multiple directed edges pointing to the same right-hand node. Record all concurrent bifurcation clusters and convergence conflict clusters as an abnormal connection set.

[0041] S312: For each concurrent bifurcation pointing cluster and each convergence conflict cluster in the abnormal connection set, perform an abnormal connection removal operation. The method for performing the abnormal connection removal operation is as follows: among the multiple directed edges contained in the concurrent bifurcation pointing cluster or the convergence conflict cluster, read the association matching score corresponding to each directed edge, retain the directed edge with the largest association matching score, and delete the remaining directed edges with non-largest association matching scores from the dynamic matching business mapping topology. When multiple directed edges in the concurrent bifurcation pointing cluster or the convergence conflict cluster have the same association matching score and are all the maximum value, retain the directed edge with the smaller row index in the node association probability matrix. Record the dynamic matching business mapping topology after performing the abnormal connection removal operation as the residual mapping topology after removal.

[0042] S313: Introduce mandatory component filling requirement clauses in the general alarm form of the fire protection integrated management platform, and perform verification on the remaining mapped topology after removal. The mandatory component filling requirement clauses refer to the set of fields that the fire protection integrated management platform requires to exist when receiving standardized messages. These mandatory component filling requirement clauses are extracted from the standard field names in the fire protection standard field table where the value of the mandatory field identifier is "yes". The verification method is as follows: traverse each mandatory field standard name in the mandatory component filling requirement clauses and check whether there are directed edges pointing to the standard entity node corresponding to the mandatory field standard name in the remaining mapped topology after removal. When it is found that there are no directed edges pointing to the standard entity node corresponding to a certain mandatory field standard name in the remaining mapped topology after removal, a critical path missing situation is determined. For cases where the critical path is missing, the following structural constraint processing steps are performed: A virtual directed edge is created, with its source being a low-level placeholder node. The load information at the corresponding position of this low-level placeholder node is set to a default placeholder value predefined by the fire protection integrated management platform. This default placeholder value is determined based on the data type of the missing field: when the field data type is string, the default placeholder is an empty string marker "N / A"; when the field data type is integer or floating-point, the default placeholder is the value 0; when the field data type is timestamp, the default placeholder is the current system timestamp; and when the field data type is boolean, the default placeholder is false. The target end of the virtual directed edge is the missing standard entity node. The virtual directed edge is added to the post-purge mapping topology remnant. After traversing all required field standard names in the forced component filling requirement clause to complete verification and structural constraint processing, the corrected post-purge mapping topology remnant is determined as the optimal normalized mapping path set.

[0043] See Figure 7This is a schematic diagram illustrating the abnormal connection removal and default value filling provided in the embodiments of this application. For example... Figure 7 The diagram illustrates a two-way correction process for the newly generated initial business mapping topology, involving structural error prevention and cleanup, as well as fallback item filling. The upper area of ​​the diagram demonstrates how, when encountering ambiguous connections from one source to multiple points, the questionable route is scored, truncated, and cleaned based on pre-processed calculations. The lower half of the diagram, guided by the platform, dynamically constructs placeholder virtual nodes and virtual directed edges with default substitute parameters to fill in gaps. This funnel-shaped strategy of eliminating weak points and retaining strong ones, along with automatic fallback, works in parallel, perfectly meeting the reliable defense requirements of fire safety systems to prevent overall system shutdowns due to missing fields or occasional random characters. The system not only automatically resolves mapping conflicts from multiple sources but also ensures that even if the device itself misses necessary form values, the main interface parsing will not fail.

[0044] S32: Read the message syntax abstract tree retained by the original temporary storage system, strictly compare it with the rewrite, replacement and transfer rule instructions formulated by the optimal normalized mapping path set, rewrite and reorganize each node of the message syntax abstract tree and mount it into the exact category-level tree structure clearly indicated by the fire platform definition specification, and create a serialized precursor for obtaining the target tree level. Specifically, all node information is read from the message syntax abstract tree temporarily stored during step S12. A new target tree structure is created, with its hierarchical framework built according to the tree-like hierarchical connection relationship of the standardized fire data summary graph. The root node of the target tree structure corresponds to the root level node of the standardized fire data summary graph, and each level child node of the target tree structure corresponds one-to-one with each level standard entity node of the standardized fire data summary graph. Each directed edge in the optimized normalized mapping path set is traversed, and the source-end business data content of the currently traversed directed edge is read. The source-end business data content is then filled into the node load value position of the target-end standard entity node of the currently traversed directed edge in the target tree structure. When there is a bottom-level placeholder node in the optimized normalized mapping path set as a virtual directed edge at the source end, the default placeholder value of the bottom-level placeholder node is filled into the corresponding node load value position of the target tree structure. After traversing all directed edges in the optimized normalized mapping path set to complete data filling, the filled target tree structure is determined as the target tree hierarchical serialization precursor. The data structure of the target tree hierarchical serialization precursor is a multi-branch tree structure. The node name of each node in the target tree hierarchical serialization precursor is the field standard name defined in the fire protection standard field table, and the node payload value of each node is the business data content after mapping or the default placeholder value.

[0045] S33: The text format splicing and parsing suite of the activation component backend initiates the sequential structure transcription, packaging and encapsulation process of the target tree hierarchical serialization precursor to generate a standardized fire target message that conforms to the general text exchange protocol standard; Specifically, the text format splicing and parsing suite is a built-in text serialization component in the backend of the fire protection integrated management platform. This suite supports transcribing tree-like data structures into key-value pair nested text strings in depth-first traversal order. The execution process of the sequential structure transcribing and packaging process is as follows: starting from the root node of the target tree-level serialization precursor, each node is visited in depth-first traversal order. For the currently traversed non-leaf node, the node name is output and a left curly brace is appended as a nested structure start marker; for the currently traversed leaf node, the node name, colon separator, and node payload value are output; when all child nodes of a non-leaf node have been traversed, a right curly brace is output as a nested structure end marker. After traversing all nodes in the target tree-level serialization precursor and completing the text splicing, the resulting complete text string is identified as the standardized fire protection target message. See also... Figure 8 This diagram illustrates the generation of standardized target messages through data node reconstruction, as provided in this application embodiment. It shows the three-tiered flow of fragmented information units, after identification, registration, and adjustment, ultimately coalescing into a standardized exchange text format. The normalized mapping list on the left provides mounting instructions to the target node. In the middle section, based on the previously deployed graph hierarchy, numerical and code content are precisely injected, resulting in a fully-fledged tree-like graph instance. Subsequently, the leaves and main branches are sequentially parsed through a post-assembly module, encapsulating a standard text body with key pairs and curly braces. This process concretely demonstrates that normalized reconstruction truly achieves a unified protocol format conversion at the terminal. The original, disorganized, non-standard transmission material is output with a unified standard protocol appearance after a series of reconstructions, ensuring that subsequent platform modules can smoothly call its data core.

[0046] Specifically, step S3, through three stages of abnormal connection removal, structural constraint handling, and data node reconstruction and transformation, systematically corrects potential mapping conflicts and missing key fields in the dynamic matching business mapping topology, ultimately outputting a standardized fire target message conforming to the data specifications of the fire integrated management platform. In actual heterogeneous fire equipment interfacing scenarios, multiple fields in messages from different manufacturers may have high semantic similarity to the same standard entity node. While the globally optimal match obtained through the Hungarian algorithm in step S24 achieves the best overall score, it may still result in one-to-many or many-to-one mapping conflicts due to the mismatch between the number of message fields and the number of standard entity nodes. Steps S311 and S312, through systematic scanning and a selective retention strategy based on association matching scores, ensure that in the final mapping result, each source field corresponds to at most one target standard entity node, and each target standard entity node receives at most one source field's data. The structural constraint processing in step S313 addresses another type of problem: when certain mandatory fields required by the fire management platform are missing from heterogeneous original fire protection message data, the automatic filling of default placeholder values ​​ensures the structural integrity of the standardized fire protection target message and prevents abnormal interruptions in the fire management platform's reception and parsing of the standardized fire protection target message due to missing fields. Steps S32 and S33 translate the mapping relationship into actual data reconstruction and text serialization operations, realizing the transformation from abstract mapping rules to standardized fire protection target messages that can be directly transmitted and used. The standardized fire protection target message output in step S3 provides an executable data entity for the subsequent transmission, distribution, and feedback evaluation in step S4.

[0047] S4: Utilize the platform's lower-level message template push channel to transmit standardized fire target messages and obtain platform interface call feedback records. Based on the platform interface call feedback records, quantify and parse the mapping confidence evaluation value. Based on the mapping confidence evaluation value, perform experience-based solidification and reverse update of the fire business semantic dictionary. Further, step S4 includes the following steps: S41: Utilizing the alarm notification message push channel built into the fire protection integrated management platform, standardized fire target messages are presented to the front end of the third-party dashboard to perform transmission, distribution, display, and handover actions, and the bypass asynchronous communication monitoring and recording probe is activated during the transmission and distribution process. Specifically, the alarm notification message push channel is a pre-configured standardized message transmission channel in the message management module of the fire protection integrated management platform. This channel supports the distribution of standardized fire target messages to various display terminals within the fire protection integrated management platform, including the Dahua platform alarm dashboard front-end and the Sixin platform alarm dashboard front-end. The standardized fire target message output in step S33 is used as the message payload, and a transmission request is initiated to the third-party dashboard presentation front-end within the fire protection integrated management platform via the alarm notification message push channel. Simultaneously with the transmission request, a bypass asynchronous communication monitoring and recording probe is activated. This bypass asynchronous communication monitoring and recording probe is an asynchronous logging component built into the third-party interface module of the fire protection integrated management platform. It operates in a non-blocking manner beside the transmission link of the standardized fire target message, without interfering with the normal transmission process of the standardized fire target message, and is only responsible for collecting various response signals generated during transmission.

[0048] S42: Command bypass asynchronous communication monitoring and recording probe monitors and tracks the entire process of standardized fire target messages entering the target database table for rendering and presentation. It collects and packages the deep prompt response signal segments dispatched when the page loads or is fully filled, and provides platform interface call feedback records accordingly. Specifically, the bypass asynchronous communication monitoring and recording probe continuously monitors the entire process of the third-party dashboard rendering and displaying each field in the standardized fire target message after it is received and written into the target database table by the third-party dashboard presentation front-end. The target database table is the table structure in the fire integrated management platform database that stores the data displayed on the third-party dashboard. The bypass asynchronous communication monitoring and recording probe collects two types of deep prompt response signal segments: the first type is a page loading delay signal segment, which is generated when the front-end verification fails due to a mismatch between the data type of a field in the standardized fire target message and the field type constraint of the target database table, or because the field value exceeds the value range of the target database table, or because a required field value is a default placeholder value; the second type is a complete data entry success signal segment, which is generated when the third-party dashboard presentation front-end successfully writes the data of all fields in the standardized fire target message into the target database table and completes the page rendering and display. The bypass asynchronous communication monitoring and recording probe packages and organizes all collected deep-level prompt response signal segments in chronological order, and adds the initiation timestamp of the transmission and distribution request, interface type identifier, and interface call status identifier to generate a platform interface call feedback record. The data structure of the platform interface call feedback record is a structured log record, which includes six fields: interface type, interface name, interface call time, interface call status, list of page loading delay signal segments, and list of complete successful reporting signal segments.

[0049] S43: Extract the statistical data of the number of error interruption blocking and alarm triggers and the Boolean flag of successful front-end rendering from the platform interface call feedback record. Use the system multi-source reliability prediction and evaluation equation to weight and combine the two to output the mapping confidence evaluation value. Specifically, the total number of page loading delay signal segments is counted from the list of page loading delay signal segments in the platform interface call feedback records. This total number is determined as the statistical data of the number of times the error interruption blocking alarm is triggered. The data type of the statistical data of the number of times the error interruption blocking alarm is triggered is a non-negative integer. A Boolean flag indicating successful completion of front-end rendering is extracted from the interface call status field of the platform interface call feedback records. When the interface call status is successful, the Boolean flag indicates successful completion of front-end rendering is 1; when the interface call status is failed, the Boolean flag indicates successful completion of front-end rendering is 0. The statistical data of the number of times the error interruption blocking alarm is triggered and the Boolean flag indicating successful completion of front-end rendering are weighted and combined using the system multi-source reliability prediction and evaluation equation. The calculation method of the system multi-source reliability prediction and evaluation equation is as follows: Where V is the mapping confidence assessment value, B is the boolean flag indicating successful completion of front-end rendering, and E is the statistical data on the number of times error interruption blocking alarms were triggered. This is the preset maximum allowed number of error reports. The success indicator is a weighted coefficient. This refers to the error penalty weighting coefficient. The preset maximum allowable number of errors is determined based on the alarm processing fault tolerance capability of the fire protection integrated management platform. For example, the preset maximum allowable number of errors can be set to 5. The method for determining the success flag weighting coefficient and the error penalty weighting coefficient is as follows: based on the actual need that the importance of successful transmission is higher than that of error penalty in fire protection business scenarios, the success flag weighting coefficient is set to be greater than the error penalty weighting coefficient. For example, the success flag weighting coefficient can be set to 0.7, and the error penalty weighting coefficient can be set to 0.3. The range of the mapping confidence evaluation value is a closed interval from -0.3 to +0.7. For example, assuming that the front-end rendering success completion Boolean flag value is 1, the error interruption blocking alarm trigger count statistics are 2, and the preset maximum allowable number of errors is 5, then the mapping confidence evaluation value is... .

[0050] S44: Use the decision-judgment logic structure to verify whether the mapping confidence evaluation value can successfully exceed the experience self-coverage replacement boundary threshold. If the judgment condition is fully met, it means that the adaptation to the new flexible format operation is established. Then, directly extract the one-to-one unknown attribute name association equation derived from the optimal normalized mapping path set to complete the fire business semantic dictionary in the lagging state, and realize the automatic variation of heterogeneous fields following the normal evolution operation mechanism. Specifically, the method for determining the experience self-coverage replacement boundary threshold is as follows: Based on the requirements of the fire protection integrated management platform for the accuracy of normalized mapping, the average value of the mapping confidence assessment in historical successful mapping records is statistically analyzed, and 80% of this average value is taken as the experience self-coverage replacement boundary threshold. For example, the experience self-coverage replacement boundary threshold can be set to 0.45. The mapping confidence assessment value is compared with the experience self-coverage replacement boundary threshold. When the mapping confidence assessment value is greater than or equal to the experience self-coverage replacement boundary threshold, the current automated normalized mapping rule is deemed valid, and the experience solidification reverse update operation of the fire protection business semantic dictionary is executed. The execution process of the experience solidification reverse update operation is as follows: traverse each directed edge in the optimized normalized mapping path set, and check whether the English name string corresponding to the source end of the currently traversed directed edge is "unidentified category" when the fire protection core business fractal root is calculated in step S142. When the core business terminology for fire protection is "unidentified category", a new one-to-one unknown attribute name association equation is formed by combining the English name string corresponding to the source end of the currently traversed directed edge with the node name of the target end standard entity node. This one-to-one unknown attribute name association equation indicates that the English name string should belong to the business category of the field containing the target end standard entity node. The English name string in the one-to-one unknown attribute name association equation is then added to the expanded semantic tuple of the dictionary record for the corresponding field's business category in the fire protection business semantic dictionary.

[0051] See Figure 9 This is a schematic diagram of feedback-driven reverse update of the fire service semantic dictionary provided in an embodiment of this application. For example... Figure 9 The diagram illustrates in detail the deep-level error correction evolutionary closed-loop loop guided by target receptor feedback indicators and enhanced in the initial dictionary parsing capability of the system. It shows the status of the collected and returned data (rejection or complete presentation) after the unified message, after being concatenated, is pushed to the third-party display board. After obtaining a confidence score that crosses the trust standard by applying the reliability equation, the front-end activation program is triggered, injecting the previously unfamiliar and unassignable new fields or modified codes back into the static regular expression package of its familiar items. This indicates that the technology is not rigid; for the format upgrades and renaming actions that may be subtly implemented by external equipment manufacturers, the feedback correction mechanism in this diagram endows the analysis module with self-enhancing and adaptive learning capabilities, breaking through the technical bottleneck of relying on manual review and repair of the dictionary for inter-platform communication.

[0052] Specifically, step S4, through four stages of processing—transmission and distribution, feedback collection, confidence assessment, and dictionary reverse update—achieves a closed-loop optimization mechanism that uses the actual execution effect of automated normalization mapping as a feedback signal to drive the adaptive expansion of the fire service semantic dictionary. During the long-term operation and maintenance of the fire protection IoT system, third-party vendors may make non-preset format adjustments to private protocol messages, such as renaming fields or adding auxiliary fields. These new field names are not yet included in the fire service semantic dictionary, and the classification convergence calculation in step S142 will mark these new field names as "unrecognized categories." While the dynamic matching mechanisms in steps S2 and S3 can attempt to establish mapping relationships based on semantic similarity and type compatibility, the correctness of the mapping results needs actual verification. Steps S41 and S42 obtain the execution feedback of the mapping results in real business scenarios by actually pushing standardized fire target messages to the third-party dashboard presentation front-end and collecting response signals during the rendering process. Step S43 quantifies the execution feedback into a mapping confidence assessment value, providing a quantifiable basis for judging the reliability of the mapping results. Step S44 compares the mapping confidence assessment value with the empirical self-coverage replacement threshold. When the mapping result is verified to be reliable, the newly discovered field name associations are automatically solidified into the fire service semantic dictionary. This allows the fire service semantic dictionary to continuously expand and improve during system operation, so that when the same field name is encountered again, it can be directly matched without relying on dynamic semantic inference again. This dictionary adaptive update mechanism based on actual operation feedback enables the entire normalized parsing mapping system to automatically adapt to the evolution of third-party vendor protocols. It can complete the identification of new field names and the updating of mapping rules without manual intervention from engineers, fundamentally reducing the daily maintenance costs after the heterogeneous fire protection IoT terminal is connected, and avoiding parsing interruptions and data loss problems caused by untimely manual modifications. The format decoupling achieved by semantic unpacking calculation in step S1 provides pure business input that does not depend on message format for dynamic semantic matching in step S2. The global optimal matching in step S2 provides a high-quality initial mapping scheme for anomaly correction in step S3. The structural constraint processing in step S3 provides a structurally complete standardized message for transmission verification in step S4. The dictionary reverse update in step S4 further enhances the coverage of the fire service semantic dictionary in step S1. The four steps form a complete closed loop from parsing to mapping to verification to optimization. The absence of any one step will lead to the break of the closed loop and make it impossible to achieve automatic adaptation capability to non-preset format adjustments of third-party vendor protocols.

[0053] Example 2: This embodiment, based on Embodiment 1, provides a normalized parsing and mapping system for heterogeneous fire protection IoT terminal communication protocols, such as... Figure 10 As shown, it includes: The semantic decoupling module is used to acquire heterogeneous fire-fighting raw message data and fire-fighting standard field table, perform hierarchical parsing on the heterogeneous fire-fighting raw message data to obtain a message syntax abstract tree, construct a fire-fighting business semantic dictionary based on the fire-fighting standard field table, and use the fire-fighting business semantic dictionary to perform semantic decoupling calculation on the message syntax abstract tree to obtain a format decoupling semantic feature set. The mapping topology generation module is used to extract regular nodes within the business architecture to construct a standardized fire data summary map, perform feature correspondence calculation based on the standardized fire data summary map and the format decoupled semantic feature set to obtain a node association probability matrix, and generate a dynamic matching business mapping topology based on the node association probability matrix. The standardized message generation module is used to check the internal connection of the dynamic matching service mapping topology, perform abnormal connection elimination and structural constraint processing, output the optimal normalized mapping path set, and perform data node reconstruction and transformation operations on the message syntax abstract tree based on the optimal normalized mapping path set to generate a standardized fire target message. The feedback update module is used to obtain platform interface call feedback records by transmitting the standardized fire target message through the platform's lower-level message template push channel, quantify and parse the mapping confidence evaluation value according to the platform interface call feedback record, and perform experience-based reverse update of the fire business semantic dictionary based on the mapping confidence evaluation value.

Claims

1. A normalized parsing mapping method for heterogeneous fire protection IoT terminal communication protocols, characterized in that, Includes the following steps: Obtain heterogeneous fire protection raw message data and fire protection standard field table, perform hierarchical parsing on the heterogeneous fire protection raw message data to obtain message syntax abstract tree, construct fire protection business semantic dictionary based on the fire protection standard field table, and use the fire protection business semantic dictionary to perform semantic decoupling calculation on the message syntax abstract tree to obtain format decoupling semantic feature set; Extract regular nodes within the business architecture to construct a standardized fire data summary map. Based on the standardized fire data summary map and the format decoupled semantic feature set, perform feature correspondence calculation to obtain a node association probability matrix. Generate a dynamic matching business mapping topology based on the node association probability matrix. Check the internal connection of the dynamic matching service mapping topology, perform abnormal connection elimination and structural constraint processing, output the optimal normalized mapping path set, and perform data node reconstruction and transformation operation on the message syntax abstract tree based on the optimal normalized mapping path set to generate standardized fire target messages. The standardized fire target message is transmitted to obtain the platform interface call feedback record. The mapping confidence evaluation value is quantified and parsed according to the platform interface call feedback record. The fire business semantic dictionary is then updated in reverse based on the mapping confidence evaluation value.

2. The method according to claim 1, characterized in that, The hierarchical parsing of the heterogeneous fire-fighting raw message data to obtain the message syntax abstract tree includes: Perform non-terminal symbol splitting operation on the heterogeneous fire protection original message data. Use the structural delimiter in the message format as the splitting mark. Starting from the outermost structural delimiter, identify and split each layer of nested substructures inward. Record the nesting depth value of each nested substructure relative to the outermost layer. Combine all the split nested substructures and their corresponding nesting depth values ​​to form a hierarchical splitting result set. Perform a key-value pair extraction operation on each nested substructure in the hierarchical splitting result set, extract all field names and corresponding field values ​​to form a key-value pair list. When the field value itself is a nested substructure, it is marked as a non-leaf node; when the field value is basic data that cannot be further split, it is marked as a leaf node.

3. The method according to claim 2, characterized in that, The step of performing hierarchical parsing of the heterogeneous fire-fighting raw message data to obtain a message syntax abstract tree also includes: Based on the hierarchical splitting result set and the key-value pair list, a parent-child connection relationship is constructed. The outermost structure is set as the root node. For nested substructures with a nesting depth of n, their field names are set as child nodes. The field names corresponding to the upper-level nested substructure containing the nested substructure are set as parent nodes. Directed connections are established from parent nodes to child nodes. All nested substructures are traversed to aggregate all parent-child connection relationships into a message syntax abstract tree with depth identifier.

4. The method according to claim 1, characterized in that, The construction of a fire service semantic dictionary based on the fire service standard field table includes: Extract the standard name of each field from the fire protection standard field table row by row, perform camelCase and underscore segmentation on each field standard name to decompose it into a basic semantic word sequence, and summarize and remove duplicates to obtain a set of general semantic words in the fire protection field. For each semantic word in the general semantic word set in the fire protection field, a pre-set synonym mapping table in the fire protection field is queried to expand and obtain the corresponding synonym list. Each semantic word and its synonym list are then merged to form an expanded semantic word set.

5. The method according to claim 4, characterized in that, The construction of the fire service semantic dictionary based on the fire service standard field table also includes: For each extended semantic lexical group in the extended semantic lexical group set, the regular expression configuration engine framework is used to concatenate all lexical groups with an OR relation to assemble them into a regular expression matching pattern; Each extended semantic tuple, its corresponding regular expression matching pattern, and the corresponding field data type and business category in the fire protection standard field table are assembled into a dictionary record. The field is marked as a mandatory field and then used as an additional attribute for each dictionary record. All dictionary records are then aggregated and assembled into the fire protection business semantic dictionary.

6. The method according to claim 1, characterized in that, The step of using the fire service semantic dictionary to perform semantic de-packaging calculation on the message syntax abstract tree to obtain a format decoupling semantic feature set includes: Traverse all the leaf nodes in the message syntax abstract tree, extract the node name from each leaf node as an English name string, and extract the node payload value as the corresponding position payload information. Each English name string is imported into the fire protection business semantic dictionary to perform classification convergence calculation. The regular expression matching pattern of each dictionary record is used for matching in turn. The ratio of the number of matched characters to the total number of characters is calculated as the belonging score. The dictionary record with the highest belonging score is selected to extract the business category to which the field belongs and determine it as the core fire protection business fractal root.

7. The method according to claim 6, characterized in that, The semantic unpacking calculation also includes: Identify the numerical memory format category of the corresponding positional payload information of each terminal node, and sequentially perform integer format determination, floating-point number format determination, timestamp format determination and Boolean format determination to determine the numerical memory format category; The numerical memory format category, the fire protection core business fractal root, and the corresponding positional load information of each terminal node are encapsulated into a semantic feature record, and all semantic feature records are aggregated to form the format decoupled semantic feature set.

8. The method according to claim 1, characterized in that, The step of calculating the node association probability matrix by performing feature correspondence calculation based on the standardized fire data induction map and the format decoupled semantic feature set includes: Semantic feature records are extracted one by one from the decoupled semantic feature set as business feature sub-pieces to be compared in a loop. For each business feature sub-piece to be compared in a loop, all standard entity nodes are traversed. The Levinstein edit distance between the fire core business fractal root and the node name is calculated and inversely proportional to obtain the character relevance evaluation score. The allowable overlap width between the numerical memory format category and the node's mandatory input data format is compared to obtain the type fit judgment score. The two scores are weighted and merged by combining the feature operator coefficient weights to obtain the association matching score.

9. The method according to claim 8, characterized in that, The process of generating a dynamic matching service mapping topology based on the node association probability matrix includes: Arrange the association matching scores between all the cyclic business feature sub-pieces to be compared and all the standard entity nodes to form the node association probability matrix; call the Hungarian algorithm on the node association probability matrix, and under the constraint that each left node matches at most one right node and each right node matches at most one left node, search for a matching scheme that maximizes the sum of global association matching scores, and establish the dynamic matching business mapping topology based on the matching scheme.

10. The method according to claim 1, characterized in that, The abnormal connection removal and structural constraint processing include: Scan the dynamic matching service mapping topology to see if there are concurrent branching clusters or convergence conflict clusters. For abnormal connections, retain the directed edge with the highest association matching score and delete the rest of the directed edges to obtain the remaining mapping topology after removal. A mandatory component filling requirement clause is introduced to perform verification on the removed mapping topology remnants. When the standard entity node corresponding to the required field does not have a directed edge pointing to it, a virtual directed edge is created and the default placeholder value determined according to the field data type is used as the source data to complete it. The corrected result is determined as the optimal normalized mapping path set.

11. The method according to claim 1, characterized in that, The step of reconstructing and transforming data nodes of the message syntax abstract tree based on the optimized normalized mapping path set to generate standardized fire target messages includes: Create a target tree structure. The hierarchical framework of the target tree structure is built according to the tree-like subordinate connection relationship of the standardized fire data summary map. Traverse each directed edge in the optimal normalized mapping path set and fill the source business data content into the corresponding node load value position of the target standard entity node in the target tree structure to obtain the target tree hierarchical serialization precursor. The target tree-level serialization precursor is serialized using a depth-first traversal to generate the standardized fire target message conforming to the Common Text Exchange Protocol standard.

12. A normalized parsing mapping system for heterogeneous fire protection IoT terminal communication protocols, characterized in that, include: The semantic decoupling module is used to acquire heterogeneous fire-fighting raw message data and fire-fighting standard field table, perform hierarchical parsing on the heterogeneous fire-fighting raw message data to obtain a message syntax abstract tree, construct a fire-fighting business semantic dictionary based on the fire-fighting standard field table, and use the fire-fighting business semantic dictionary to perform semantic decoupling calculation on the message syntax abstract tree to obtain a format decoupling semantic feature set. The mapping topology generation module is used to extract regular nodes within the business architecture to construct a standardized fire data summary map, perform feature correspondence calculation based on the standardized fire data summary map and the format decoupled semantic feature set to obtain a node association probability matrix, and generate a dynamic matching business mapping topology based on the node association probability matrix. The standardized message generation module is used to check the internal connection of the dynamic matching service mapping topology, perform abnormal connection elimination and structural constraint processing, output the optimal normalized mapping path set, and perform data node reconstruction and transformation operations on the message syntax abstract tree based on the optimal normalized mapping path set to generate a standardized fire target message. The feedback update module is used to transmit the standardized fire target message acquisition platform interface call feedback record, quantify and parse the mapping confidence evaluation value according to the platform interface call feedback record, and perform experience solidification reverse update on the fire business semantic dictionary based on the mapping confidence evaluation value.

Images