A dynamic perception encoding and conversion method and system for a traffic service scenario

Abstract

This invention provides a dynamic perception encoding and conversion method and system for traffic business scenarios. The method includes: constructing a metadata encoding layer to formally define metadata elements in the traffic domain and generate metadata codes; constructing a master data encoding layer to generate permanently unique static primary keys for static business data objects and temporary dynamic codes for dynamic business flows; constructing an intelligent mapping and conversion engine to establish mapping relationships between temporary dynamic codes, static primary keys, metadata codes, and business scenarios; acquiring traffic business data and encoding it through the metadata encoding layer and master data encoding layer; and when receiving a data request containing temporary dynamic codes or interacting with external systems, querying the mapping relationship through the intelligent mapping and conversion engine to parse or convert it into a target code conforming to external standards. This invention provides efficient and unified encoding support for a traffic full lifecycle data foundation.

Description

Technical Field

[0001] This invention relates to the field of data processing technology for traffic business scenarios, and in particular to a dynamic perception coding and conversion method and system for traffic business scenarios. Background Technology

[0002] With the deepening of intelligent transportation construction, the transportation industry is accelerating its transformation towards digitalization, connectivity, and intelligence. This transformation permeates all business scenarios throughout the entire lifecycle, including planning and design, construction, operation and maintenance, and travel services, generating massive amounts of multimodal, multi-source, and heterogeneous data, including but not limited to BIM / CAD design models, IoT monitoring data, vehicle trajectory data, facility status information, dispatch logs, and passenger travel data. Achieving deep integration and efficient collaboration between these static facility and dynamic operational data has become crucial for improving the overall efficiency of the transportation system. However, inherent defects in the current data coding system severely restrict the realization of this goal.

[0003] First, the existing classification and coding standards are numerous and incompatible, leading to a severe "data silo" phenomenon. On the transportation infrastructure side, multiple standards exist both domestically and internationally, such as the "Classification and Coding Standard for Building Information Modeling" (GB / T 51269-2017), IFC, and OmniClass. On the transportation operation side, the identification rules for vehicle VIN codes, flight numbers, and signal control schemes also vary. These standards differ significantly in classification methods, hierarchical structures, and coding rules, creating significant obstacles to data interaction between roadside facility data and vehicle operation data, as well as between different business systems. To achieve cross-system collaboration, complex, fragile, and difficult-to-maintain manual mapping rules are often required, greatly increasing the cost and complexity of data fusion and hindering the formation of end-to-end business collaboration capabilities.

[0004] Secondly, existing coding designs are generally overly cumbersome and fail to effectively distinguish and adapt to the two fundamentally different data objects and their usage scenarios: static core assets and dynamic business flows. For static core assets such as bridges and vehicles, their coding should strive for permanent uniqueness and stable traceability. However, current solutions often use lengthy, complex strings that embed a large amount of manually readable information such as classification and region. This not only results in complex rules for generating and maintaining the data and high upfront costs, but also inefficient database indexing. For dynamic business data such as inspection records and real-time trajectories, their coding should meet the needs of high-frequency, instantaneous interaction, emphasizing extreme lightweightness and temporary scenarios. However, existing technologies often directly reuse the lengthy coding of static assets or design another set of equally cumbersome rules. This uniform coding method, which does not distinguish between object characteristics and scenario requirements, results in huge overhead for transmission, serialization / deserialization, and storage in high-concurrency, low-latency machine-to-machine automated interaction scenarios such as microservice interfaces, V2X communication in the Internet of Vehicles, and edge computing. This causes unnecessary waste of resources throughout the entire chain from generation and maintenance to use, becoming a key bottleneck in system performance and failing to meet the high-efficiency operation requirements of real-time intelligent transportation services.

[0005] Furthermore, to ensure compatibility with existing business systems and data standards, any new coding mechanism must possess the ability to dynamically and losslessly convert with the existing coding system. However, traditional static data coding mapping methods lack flexibility and efficiency, making it difficult to adapt to the rapid iteration and ever-changing relationships characteristic of new transportation business scenarios. Therefore, the industry urgently needs a new coding scheme that can fundamentally overcome the problems of lengthy and inefficient existing coding, providing lightweight identifiers for machine-to-machine interaction, and ensuring smooth interoperability with various existing standard codes through an intelligent dynamic conversion mechanism, thereby providing core support for building an efficient and unified intelligent transportation data foundation. Summary of the Invention

[0006] To address the aforementioned problems in the prior art, this invention provides a dynamic perception coding and conversion method and system for traffic business scenarios, enabling efficient and unified full lifecycle management of traffic data.

[0007] To achieve the above objectives, the technical solution adopted by the present invention is as follows: In a first aspect, the present invention provides a dynamic sensing encoding and conversion method for traffic business scenarios, comprising: Step S1: Construct a metadata encoding layer, formally define multiple metadata elements in the transportation field, and generate a globally unique metadata code for each metadata element. The metadata elements include at least entities, attributes, relationships, and business scenarios. Step S2: Construct the master data encoding layer. Based on the metadata encoding, generate a permanently unique static primary key for static business data objects and generate a temporary dynamic code for dynamic business processes. The temporary dynamic code is generated with business scenario code, static primary key, timestamp and random number as input parameters. Step S3: Construct an intelligent mapping and transformation engine to establish a mapping relationship between the temporary dynamic code and the static primary key, the metadata code, and the business scenario; Step S4: Obtain traffic business data and encode the traffic business data through the metadata encoding layer and the master data encoding layer; Step S5: When a data request containing temporary dynamic encoding is received, the mapping relationship is queried through the intelligent mapping and conversion engine to parse out the corresponding static primary key, metadata encoding and business scenario; Step S6: When interaction with external systems is required, the metadata encoding is mapped to a target encoding that conforms to external standards and output through the intelligent mapping and conversion engine.

[0008] The beneficial effects of this invention are as follows: by constructing a metadata encoding layer, a master data encoding layer, and an intelligent mapping and conversion engine, and adopting a dynamic and static separation encoding strategy, while dynamically converting the metadata encoding into target encoding that conforms to external standards when interaction with external systems is required, the transmission and storage overhead in high-concurrency machine-to-machine interaction scenarios is systematically reduced, millisecond-level context parsing of dynamic encoding is achieved, and cross-standard interoperability with heterogeneous standards is established, providing efficient and unified encoding support for the transportation full lifecycle data foundation.

[0009] Optionally, the metadata encoding layer further defines data elements and / or data models. The data element is the smallest data unit formed by the association of entities, attributes, and business scenarios. The data model is a data structure template composed of multiple data elements according to preset rules.

[0010] As described above, by further defining data elements and / or data models at the metadata encoding layer, the same entity can dynamically associate different attribute sets and reuse standardized data structures in different business scenarios, thereby significantly improving the flexibility of data organization and modeling efficiency in multiple business scenarios, and avoiding data redundancy or duplicate definitions caused by scenario switching.

[0011] Optionally, the temporary dynamic code is set with an expiration period and a maximum number of uses, and after each use, the number of uses and the last use time of the temporary dynamic code are updated; When the current usage count reaches the maximum usage count or the current time exceeds the validity period, the temporary dynamic code will be automatically marked as invalid.

[0012] As described above, by setting an expiration date and a maximum number of uses for temporary dynamic codes, refined lifecycle management of dynamic codes is achieved. This not only ensures the security of temporary tokens in high-frequency business scenarios, but also avoids invalid codes occupying system resources for a long time through an automatic expiration mechanism, thereby improving system security and resource utilization efficiency.

[0013] Optionally, step S3 further includes: Build a multi-rule encoding library to store multiple encoded values ​​under multiple encoding rules for the same metadata object or the same static primary key object, and specify one of them as the primary identifier key; The primary identifier key is dynamically switched when a change in business scenario is detected, and the multi-rule encoding library supports using industry standard encoding as one of the encoding rules to achieve dynamic mapping with external standards.

[0014] As described above, by constructing a multi-rule coding library, the system can efficiently process data internally while seamlessly being compatible with various existing standards externally. This eliminates the need for manually creating and maintaining complex mapping tables, thereby significantly reducing the cost and complexity of cross-system data fusion and enhancing the scalability and adaptability of the coding system.

[0015] Optionally, it also includes: When the metadata encoding changes, the fields referencing that metadata encoding in the mapping relationship between the static primary key and the temporary dynamic encoding are automatically updated; When the primary identifier key of the static primary key changes, the static primary key value referenced in the temporary dynamic encoding generation algorithm is automatically updated.

[0016] Optionally, the metadata encoding is mapped to a target encoding conforming to an external standard for output, including: Identify the external coding standard used by the target system; Query the preset encoding mapping table and map the metadata encoding to the encoding value under the external encoding standard; The data is assembled and output according to the data format of the external encoding standard.

[0017] Optionally, it also includes: Record the lifecycle status of each temporary dynamic code; The system automatically manages the validity, invalidation, or expiration status of temporary dynamic codes by using the status fields, generation time, expiration time, maximum number of uses, and current number of uses in the mapping table.

[0018] Optionally, it also includes: Record the mapping relationship between object identifier, data level, encoding rule type, encoding value, and whether it is the main identifier to the multi-rule encoding library; When a new business scenario or data standard is detected, the encoding rule types in the multi-rule encoding library are automatically added or updated.

[0019] Optionally, the static primary key is a globally unique permanent identifier that is not embedded in business semantics, and the temporary dynamic code is only valid within the context of its business scenario and automatically expires when the session ends or the preset number of uses is reached.

[0020] Secondly, the present invention provides a dynamic perception encoding and conversion system for traffic business scenarios, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the dynamic perception encoding and conversion method for traffic business scenarios described in the first aspect below.

[0021] The technical effects of the dynamic perception coding and conversion system for traffic business scenarios provided in the second aspect are described in the relevant description of the dynamic perception coding and conversion method for traffic business scenarios provided in the first aspect. Attached Figure Description

[0022] Figure 1 This is a schematic diagram of the main process of a dynamic perception coding and conversion method for traffic business scenarios according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the framework of a dynamic perception coding and conversion method for traffic business scenarios according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the interface for entity encoding involved in an embodiment of the present invention; Figure 4 This is a schematic diagram of the interface for attribute encoding involved in an embodiment of the present invention; Figure 5 This is a schematic diagram of the interface for relational encoding involved in an embodiment of the present invention; Figure 6 This is a schematic diagram of the interface encoding for the business scenario involved in an embodiment of the present invention; Figure 7 This is a schematic diagram of the interface for data element encoding involved in an embodiment of the present invention; Figure 8 This is a schematic diagram of the interface encoding of the data model involved in an embodiment of the present invention; Figure 9 This is a schematic diagram of the interface for static data encoding according to an embodiment of the present invention; Figure 10 This is a schematic diagram of the structure of a dynamic perception coding and conversion system for traffic business scenarios according to an embodiment of the present invention.

[0023] Explanation of reference numerals in the attached figures: 1: A dynamic perception coding and conversion system for traffic business scenarios; 2: Processor; 3: Memory. Detailed Implementation

[0024] To better understand the above technical solutions, exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present invention are shown in the drawings, it should be understood that the present invention can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that the present invention can be understood more clearly and thoroughly, and that the scope of the present invention can be fully conveyed to those skilled in the art.

[0025] Example 1 Please refer to Figures 1 to 9 A dynamic perception coding and conversion method for traffic business scenarios includes the following steps: Step S1: Construct a metadata encoding layer, formally define multiple metadata elements in the transportation field, and generate a globally unique metadata code for each metadata element. Metadata elements include at least entities, attributes, relationships, and business scenarios.

[0026] In this embodiment, the metadata encoding layer also defines data elements and / or data models. A data element is the smallest data unit formed by the association of an entity, attributes, and business scenarios. A data model is a data structure template composed of multiple data elements combined according to preset rules. This allows the same entity to dynamically associate with different attribute sets and reuse standardized data structures in different business scenarios, significantly improving the flexibility and modeling efficiency of data organization across multiple business scenarios and avoiding data redundancy or duplicate definitions caused by scenario switching.

[0027] Specifically, the metadata encoding layer is the semantic foundation of the entire implementation system, aiming to provide a unified and standardized conceptual description framework for the digital management of all traffic scenarios. This layer adopts a standardized encoding scheme to formally define and uniquely identify the core elements within the business domain, thereby providing accurate type constraints and semantic context for the data instantiation processing of the lower layer. The core elements include entities, attributes, relationships, business scenarios, data elements, and data models.

[0028] This embodiment uses tunnel asset management as a business scenario and designs a rigorous and scalable composite identifier encoding rule for all metadata objects. This general rule adopts a three-part structure of "prefix_type identifier_serial number". Wherein: a. Prefix: Fixed identifier used to distinguish metadata types, such as ENT for entities and ATTR for attributes.

[0029] b. Type identifier: A 3-character uppercase code, generated from the object's English name using a priority-based algorithm to ensure its semantic clarity and ease of recognition, such as the initial letter method or the vowel removal method.

[0030] c. Serial number: 4 digits, starting from 0001, used to distinguish different objects under the same type or when the prefix is ​​consistent with the identifier, supporting large-scale expansion.

[0031] This encoding structure ensures global uniqueness while also offering good readability and machine processing efficiency, laying a solid foundation for accurate data location, related queries, and dynamic assembly.

[0032] Therefore, the encoding definitions of each core element are as follows: 1. Entity Coding Definition like Figure 3 As shown, an entity is a business object with a clear conceptual boundary and independent identity. It is the core unit for data classification and organization, such as "tunnel," "lining," and "electromechanical facilities." Entity codes are used to uniquely identify these business object types. Entity codes follow the aforementioned general composite identification rules, and their standard format is: ENT_Type Identifier_Sequence Number.

[0033] Specifically, the general rules for composite identifiers include: a. Rule 1: First Letter Method Prioritize using the first letter combination of each word in the entity's English name. This is suitable for names consisting of multiple words.

[0034] Example: Civil Structure → CVS b. Rule 2: First-Middle-Tail Method For a single word, take the first letter, the key consonant in the middle, and the last letter.

[0035] Example: Structure: Take Struct → STC c. Rule 3: Syllable Method When rule two cannot be clearly expressed, take the first letter of the first two syllables and the first letter of the last syllable, or the prominent syllable of the word.

[0036] Example: Camera → CAM d. Rule 4: Vowel Removal Method Preserving the core consonants of a word usually preserves its "skeleton" very well. This is a very effective method.

[0037] Example: Button → BTN e. Rule 5: Industry Practice Law If an abbreviation already has an industry standard, it can be used directly to ensure professionalism. Alternatively, the abbreviation obtained from the above rules can be used directly.

[0038] Example: The abbreviation TFR is obtained by Transformer using the above rules, while the abbreviation commonly used in the power industry is XFMR. You can choose the more intuitive TFR or the more professional XFMR.

[0039] Therefore, the entity encoding example in this embodiment is shown in Table 1.

[0040] Table 1. Entity Coding

[0041] 2. Attribute encoding definition like Figure 4 As shown, attributes are various indicators used to describe the static characteristics or dynamic state of an entity, such as "length," "material type," and "structural form." Attribute coding is used to uniquely identify these descriptive characteristics.

[0042] The standard format for attribute encoding is ATTR_type identifier_serial number. The generation rules for its type identifier are consistent with those for entity encoding, ensuring consistency across the entire system.

[0043] Therefore, the attribute encoding example in this embodiment is shown in Table 2.

[0044] Table 2, Attribute Coding

[0045] 3. Relational coding definition like Figure 5 As shown, relations are used to describe the relationships and interactions between entities or between entities and attributes, such as "structural resolution" and "spatial topology." Relational encoding is used to uniquely identify these association rules.

[0046] The standard format for relational encoding is REL_type identifier_serial number.

[0047] Therefore, the relation encoding example in this embodiment is shown in Table 3.

[0048] Table 3. Relationship Coding

[0049] 4. Business Scenario Coding Definition like Figure 6As shown, a business scenario is a standardized definition of a specific business process or task, such as "daily inspection" or "asset management." Its core value lies in solving the problem of data view differences for the same core asset under different business needs. Through standardized definitions, it configures exclusive data association rules for specific business tasks such as asset management and daily inspections, enabling the same entity to be associated with different attributes to form differentiated data elements as needed. It also allows for the flexible combination of different entities to construct specific data models, thereby supporting the accurate, efficient, and personalized data usage needs of multiple business flows while ensuring the uniqueness of the data source. The business scenario code is used to identify different business contexts for the same entity in different business scenarios.

[0050] The standard format for business scenario coding is SCENE_Type Identifier_Sequence Number.

[0051] Therefore, the business scenario coding example of this embodiment is shown in Table 4.

[0052] Table 4. Business Scenario Coding

[0053] 5. Data element encoding definition like Figure 7 As shown, a data element is the smallest data unit with business significance formed by associating entities and attributes in a specific business scenario. Its encoding format is: DE_entity identifier_scenario identifier_serial number, which intuitively reflects "which entity" possesses which attribute sets in "what scenario".

[0054] Therefore, Table 5 shows some examples of data element encoding in the asset management scenario of this embodiment.

[0055] Table 5. Partial Data Element Codes in Asset Management Scenarios

[0056] 6. Data Model Coding Definition like Figure 8 As shown, a data model is a reusable data structure template composed of multiple data elements combined according to specific business rules. The implementation of a single business scenario usually requires the collaborative support of multiple data models. Taking the daily inspection scenario of tunnels as an example, its complete business process relies on both a structural analysis data model centered on physical components such as lining and lighting facilities to organize assets and attributes, and a business process data model centered on task nodes such as inspection plans and execution records to drive business flow.

[0057] Given that each data model has a core node or starting node, its encoding format adopts a four-segment structure: DM_core entity identifier_scene identifier_serial number, which identifies a complete data structure with a certain entity as the core and serving a specific scenario.

[0058] Therefore, the data model encoding example of this embodiment is shown in Table 6.

[0059] Table 6. Data Model Coding

[0060] In this embodiment, the metadata encoding layer possesses dynamic switching and intelligent mapping capabilities across multiple encoding schemes. Its core lies in constructing an extensible encoding rule base and mapping relationship table, supporting the use of multiple encoding rule algorithms for the same metadata object across different systems. The composite encoding rule described in this embodiment is merely one basic implementation scheme within the rule base; the system can flexibly configure and switch to other encoding rules according to actual business needs.

[0061] 1. Multi-rule base architecture Multiple encoding strategies are supported by constructing an extensible encoding rule base. This rule base not only includes the composite identifier rules described in this embodiment, but also pre-configures various strategies such as industry standard mapping rules for conversion to IFC and OmniClass standards, and numeric abbreviation rules. More importantly, the system supports configuring multiple rules for the same metadata object, and records and maintains the association relationships between different encodings through a core many-to-many mapping table, thereby forming an encoding matrix.

[0062] 2. Intelligent mapping mechanism Intelligent mapping mechanisms are crucial in data exchange scenarios. When a system needs to interact with external systems that adhere to different standards, such as a BIM system using the IFC standard, the intelligent mapping and conversion engine initiates a dynamic switching process. The engine first identifies the target system's coding requirements, then queries the mapping table to convert the internal coding into an external coding that the target system can recognize in real time; for example, converting an entity's ENT_TNL_0001 to IfcTunnel. This process is transparent to internal business logic, ensuring the stability of internal processing while achieving seamless external compatibility.

[0063] Therefore, by constructing a multi-rule coding library, the system can efficiently process data internally while seamlessly being compatible with various existing standards externally. This eliminates the need for manually creating and maintaining complex mapping tables, thereby significantly reducing the cost and complexity of cross-system data fusion and enhancing the scalability and adaptability of the coding system.

[0064] Step S2: Construct the master data encoding layer. Based on metadata encoding, generate a permanent and unique static primary key for static business data objects and generate temporary dynamic codes for dynamic business flows. The temporary dynamic codes are generated with business scenario codes, static primary keys, timestamps and random numbers as input parameters.

[0065] Among them, the master data encoding layer is an instantiation extension of the metadata encoding layer, and is responsible for generating operation identifiers for specific business objects.

[0066] Among them, the static primary key is a globally unique permanent identifier that is not embedded in business semantics, while the temporary dynamic encoding is only valid within the context of its business scenario and automatically expires when the session ends or the preset number of uses is reached.

[0067] In this embodiment, as Figure 9 As shown, static data encoding paths are specifically designed for core, long-lifecycle, and stable assets or records that need to be permanently stored in transportation infrastructure, such as a specific tunnel, a particular bridge, and as-built drawings. Its core objective is to assign these static business data a permanently unique and stable digital primary key throughout their entire lifecycle, serving as their authoritative identity identifier in the digital world—this is the static primary key.

[0068] This embodiment uses tunnel asset management as an example to illustrate the specific implementation method of static data encoding. Static business data refers to core business objects that require permanent identification, such as tunnel assets, design units, and construction units. To address the requirements of encoding length and ease of use, this embodiment uses a mixed numeric and alphanumeric code as the static business data identifier.

[0069] 1. Objectives and Scope of Static Data Coding Static data encoding paths are specifically designed for core business objects in transportation infrastructure that require permanent identity storage. This type of data differs fundamentally from dynamic business transaction data: its core value lies in the stability of its identity throughout its entire lifecycle, serving as the cornerstone of business operations and necessitating long-term storage and cross-system referencing. Therefore, the design goals of static data encoding are global uniqueness, permanent stability, and scenario independence. It is optimized for scenarios such as data governance, cross-system unique identification, and full lifecycle traceability, ensuring the authoritative and traceable digital identity of core business objects.

[0070] This section uses tunnel asset management as an example to elaborate on the generation mechanism, structural characteristics, and application of static data coding in business governance. The static data coding path follows the following core design principles: (1) Global uniqueness: The code is globally unique within the system and even across systems, avoiding identification conflicts in any scenario and ensuring that each business object instance has a unique digital identity.

[0071] (2) Permanent stability: Once generated, the code remains unchanged throughout the entire lifecycle of the object and will not become invalid due to business changes, system upgrades or the passage of time, ensuring the long-term traceability of data records.

[0072] (3) Scenario independence: The code itself does not embed business semantics, so that it can be stably referenced across different business scenarios and avoid the code from becoming invalid due to changes in business scenarios, such as asset management, design management and operation and maintenance management, etc.

[0073] (4) Highly efficient indexing: The encoding format is suitable as a database primary key or index, supports efficient data retrieval and related queries, and meets the performance requirements of large-scale data governance.

[0074] (5) Machine readability: The code is optimized for machine processing rather than human reading to ensure processing efficiency in automated data exchange and system integration.

[0075] 2. Static data encoding generation algorithm In tunnel asset management, static business data refers to core business objects whose identities need to be permanently stored. To balance uniqueness and storage efficiency, this embodiment adopts a customized 32-character ShortUnordered Code-32 (SUC-32) algorithm, which significantly improves storage and transmission efficiency while ensuring uniqueness.

[0076] 2.1 SUC-32 Algorithm Structure The SUC-32 algorithm generates a unique 32-character identifier by combining a timestamp, a random sequence, and a check bit. This identifier uses uppercase hexadecimal characters 0-9 and AF, and explicitly excludes easily confused letters O, I, and L to ensure clarity and accuracy. The algorithm structure is as follows.

[0077] Timestamp segment: 10 characters, taking the first 10 hexadecimal characters of the SHA-256 hash value of the current timestamp to ensure that the encoding is time-related, where the current timestamp is in milliseconds.

[0078] Random number segment: 21 characters, generated using a cryptographically secure pseudo-random number generator to ensure global uniqueness of the encoding.

[0079] Check segment: 1 character. The first 31 characters of the binary representation are subjected to CRC8 cyclic redundancy check calculation. The lower 4 bits of the check value are taken as 1 hexadecimal character to detect errors that may occur in the encoding during transmission or storage.

[0080] 2.2 Encoding Generation Process Taking the creation of the "Nanshan Tunnel" asset as an example, the SUC-32 static data encoding generation process is as follows: Step 1: The system confirms that the asset type is "tunnel" and the metadata code is ENT_TNL_0001.

[0081] Step 2: Generate SUC-32 code (1) Get the current timestamp, for example: 1737945000000, calculate its SHA-256 hash value and take the first 10 bits to get the timestamp segment, for example A3F9B7C2D8.

[0082] (2) Generate a 21-bit random hexadecimal string as a random number segment, such as E1F4A6B5C7D9E0F1A2B3C.

[0083] (3) Concatenate the timestamp segment and the random number segment obtained in the first two steps to form a total of 31 characters, for example: A3F9B7C2D8E1F4A6B5C7D9E0F1A2B3C, and calculate its CRC8 check value. Assuming the result is 5, then the check segment is 5.

[0084] (4) Combine the three segments to generate a complete SUC-32 code. For example, the example values ​​in (1) to (3) above are combined to obtain: A3F9B7C2D8E1F4A6B5C7D9E0F1A2B3C5.

[0085] Step 3: Binding and Storage. Associate the generated SUC-32 code with metadata encoding ENT_TNL_0001, asset name "Nanshan Tunnel", and other information, and write it into the static data encoding mapping table.

[0086] 2.3 Conflict Resolution Mechanism To ensure the global uniqueness of SUC-32 codes, the following mechanisms can be implemented for conflict resolution: (1) When generating new codes, the deduplication table is queried in real time to perform collision detection.

[0087] (2) If a duplicate is detected, the system will automatically regenerate a random number segment, and will retry a maximum of 5 times.

[0088] (3) All generated codes and their status will be recorded, fundamentally preventing duplicate allocation.

[0089] 3. Structure and Function of Static Data Encoding Mapping Table The static data encoding mapping table is not only the hub connecting instance identifiers (SUC-32 code) and type semantics (entity code), but also the key to binding static business data with specific business scenarios. When a static business data object (such as "Nanshan Tunnel") is instantiated under a specific business scenario (such as "asset management"), its complete data view is defined by the associated data elements. Therefore, recording its association with data element codes in the static data encoding mapping table is the core mechanism to ensure that the object can be automatically associated with the correct attribute set in business processing. For example, if the static business data object is Nanshan Tunnel and the specific business scenario is asset management, then the static data encoding mapping table example is shown in Table 7.

[0090] Table 7. Static Data Encoding Mapping Table

[0091] This embodiment selects SUC-32 code as the primary key, avoiding the overhead of an additional id field, simplifying the table structure, and ensuring that the business meaning of the primary key is clear.

[0092] The `data_element_code` field provides a finer-grained association with the default business attribute view, while the `data_model_code` field provides a coarser-grained association with the complete business data structure. This design offers flexibility: for a tunnel asset, it can be simultaneously bound to the asset management data model DM_TNL_ASM_0001, and its default data element view, such as DE_TNL_ASM_0001, can be specified under that model.

[0093] In this embodiment, the dynamic data encoding path of the master data encoding layer is specifically designed to handle business transaction records that are generated frequently in specific business scenarios and have clear timeliness. This type of data differs fundamentally from static core asset data: its core value lies within a specific business context and a limited time window, with a short lifespan that expires upon session termination. Therefore, the design goal of dynamic encoding is extreme lightweighting, scenario-based application, and temporariness, optimized specifically for high-frequency API calls and message passing between machines, to minimize network transmission and computational overhead.

[0094] Therefore, in this embodiment, the temporary dynamic code has a validity period and a maximum number of uses. For example, the validity period is typically set to 24 hours, and the maximum number of uses can be 10. It also includes: After each use, update the number of times the temporary dynamic code has been used and the last time it was used. When the current usage count reaches the maximum usage count or the current time exceeds the validity period, the temporary dynamic code will be automatically marked as invalid. Record the lifecycle status of each temporary dynamic code; The system automatically manages the validity, invalidation, or expiration status of temporary dynamic codes by using the status fields, generation time, expiration time, maximum number of uses, and current number of uses in the mapping table.

[0095] When the metadata encoding changes, the fields referencing that metadata encoding in the mapping relationship between the static primary key and the temporary dynamic encoding are automatically updated; When the primary identifier key of the static primary key changes, the static primary key value referenced in the temporary dynamic encoding generation algorithm is automatically updated.

[0096] Specifically, this embodiment takes two typical business scenarios, tunnel asset management and daily inspection, as examples to elaborate in detail on the generation mechanism, structural characteristics, and application of dynamic data encoding in business processes.

[0097] 1. Positioning and Design Principles of Dynamic Data Encoding Dynamic data is generated from specific business operations, such as an asset inventory record, a daily inspection result, a maintenance work order, or a real-time alarm message. This data shares the following characteristics: high generation frequency, strong timeliness, and close connection to specific business scenarios and static asset instances.

[0098] This embodiment uses tunnel asset management and daily inspection operations as an example to elaborate on the generation mechanism, structural characteristics, and role of dynamic data encoding in business applications. The dynamic data encoding path follows the following core design principles: (1) Lightweight: The encoding length is significantly shorter than that of static encoding, usually 8-16 characters, which minimizes network transmission and data storage overhead.

[0099] (2) Scene awareness: When the code is generated, the business scene information and the target static asset information are deeply embedded, that is, scene coding and static coding, so that it carries business semantics.

[0100] (3) Timeliness: The code has a clear life cycle and expires automatically, ensuring the security and cleanliness of the system, such as 24 hours.

[0101] (4) Parsability: Through the intelligent mapping and conversion engine, the key context information such as the business scenario and target assets corresponding to the code can be quickly parsed to support business logic processing.

[0102] 2. Dynamic Data Encoding Generation Algorithm This embodiment employs a lightweight generation scheme based on a hash algorithm for dynamic data encoding. Its core design principle is to use key business context information as input and directly generate a fixed-length hexadecimal string through hash operations, completely removing prefix identifiers to achieve extreme simplicity. The encoding length is fixed at 8 bits, optimized specifically for high-frequency, lightweight machine-to-machine interaction scenarios.

[0103] 2.1 Algorithm Input Elements and Standardization Preprocessing The generation of dynamic codes relies on the following core input elements to ensure their uniqueness and parsability, as detailed in Table 8.

[0104] Table 8. Description of Dynamic Coding Input Elements

[0105] 2.2 Input String Concatenation Standards The input parameters are concatenated in a strict order and with separators to form a standardized input string: scene code | static code | timestamp | random number.

[0106] The concatenation order and delimiter selection are carefully designed to ensure that even if some parameter values ​​are the same, different positions will produce completely different hash results.

[0107] 2.3 Hash Calculation and Encoding Generation Process Step 1: String concatenation Connect the preprocessed parameters in a fixed order using the "|" symbol.

[0108] Step 2: SHA-256 hash calculation Perform a SHA-256 hash operation on the concatenated complete string to generate a 256-bit hash value. At this point, the hash value is 64 characters.

[0109] Step 3: Encoding Extraction The first 8 hexadecimal characters of the SHA-256 hash value are used as the final dynamic encoding. The 8-bit length ensures uniqueness while achieving extreme simplicity in encoding.

[0110] 2.4 Specific Examples of Asset Management Scenarios (1) Scene context: At 10:30:00 UTC on January 27, 2026, an asset appraisal was conducted on "Nanshan Tunnel" (static code A3F9B7C2...C5).

[0111] (2) Input parameters: Business scenario code: SCENE_ASM_0001; Target static asset code: A3F9B7C2D8E1F4A6B5C7D9E0F1A2B3C5; Timestamp: 1737945000000; Random number: 123456.

[0112] (3) Parameter concatenation: The above input parameters are concatenated to obtain the complete string: SCENE_ASM_0001|A3F9B7C2D8E1F4A6B5C7D9E0F1A2B3C5|1737945000000|123456.

[0113] (4)SHA-256 calculation: The hash value obtained by hashing the complete string is: a5c7e3f1b2d4a6c8e0f2b4d6a8c0e2a4c6e8f0b2d4a6c8e0f2b4d6a8c0e2a4c6e8.

[0114] (5) Extracting the encoding: Extract the first 8 characters: a5c7e3f1.

[0115] (6) Unify capitalization: Final dynamic encoding: A5C7E3F1.

[0116] 2.5 Specific Examples of Daily Patrol Scenario Generation (1) Scene context: At 10:31:00 UTC on January 27, 2026, a routine inspection was conducted on the same "Nanshan Tunnel".

[0117] (2) Input parameters: Business scenario code: SCENE_RIN_0001; Target static asset code: A3F9B7C2D8E1F4A6B5C7D9E0F1A2B3C5; Timestamp: 1737945000000; Random number: 654321.

[0118] (3) Parameter concatenation: The above input parameters are concatenated to obtain the complete string: SCENE_RIN_0001|A3F9B7C2D8E1F4A6B5C7D9E0F1A2B3C5|1737945060000|654321.

[0119] (4)SHA-256 calculation: The hash value obtained by hashing the complete string is: 8b3d1e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3.

[0120] (5) Extracting the encoding: Extract the first 8 characters: 8b3d1e4f (6) Unify capitalization: Final dynamic encoding: 8B3D1E4F 3. Structure and Function of Dynamic Encoding Mapping Table The dynamic coding mapping table is an intelligent hub connecting lightweight dynamic coding with the complete business context. Its core function is to realize the parsing, attribute management, and lifecycle control of dynamic coding. This table adopts the design concept of coding-attribute separation, which enables fine-grained attribute management through the mapping table while maintaining the simplicity of dynamic coding.

[0121] 3.1 Mapping Table Structure Design The dynamic encoding mapping table contains the following core fields, each of which performs a specific management function, as detailed in Table 9.

[0122] Table 9. Dynamic Encoding Mapping Table

[0123] 3.2 Attribute Value Sources and Setting Rules Each attribute field in the dynamic encoding mapping table corresponds to a specific value rule. These rules constitute a complete attribute management system, as detailed in Table 10.

[0124] Table 10. Attribute Descriptions in the Dynamic Encoding Map Table

[0125] Step S3: Build an intelligent mapping and transformation engine to establish mapping relationships between temporary dynamic encoding, static primary keys, metadata encoding, and business scenarios.

[0126] In this embodiment, step S3 further includes: Build a multi-rule encoding library to store multiple encoded values ​​under multiple encoding rules for the same metadata object or the same static primary key object, and specify one of them as the primary identifier key; Record the mapping relationship between object identifier, data level, encoding rule type, encoding value, and whether it is the primary identifier in a multi-rule encoding library; When a new business scenario or data standard is detected, the encoding rule types in the multi-rule encoding library are automatically added or updated.

[0127] Among them, the primary identifier key is dynamically switched when a change in business scenario is detected, and the multi-rule encoding library supports using industry standard encoding as one of the encoding rules to achieve dynamic mapping with external standards.

[0128] Therefore, by setting an expiration date and maximum number of uses for temporary dynamic codes, refined lifecycle management of dynamic codes is achieved. This not only ensures the security of temporary tokens in high-frequency business scenarios, but also avoids invalid codes occupying system resources for a long time through an automatic expiration mechanism, thereby improving system security and resource utilization efficiency.

[0129] Specifically, the intelligent mapping and conversion engine is the core innovative component of this invention, undertaking the crucial functions of connecting the internal coding system with external standards, coordinating different coding rules, and achieving cross-system interoperability. This engine solves the core problems of numerous coding standards, severe system silos, and low conversion efficiency in existing technologies by constructing a multi-layered, scalable mapping architecture.

[0130] 1. Multiple encoding rule bases and dynamic switching mechanism To adapt to the coding needs of different business systems, the intelligent mapping and conversion engine has built a unified multi-rule coding library, which supports the use of multiple coding algorithms in the metadata coding layer and master data coding layer, and dynamically selects the primary identifier key according to the business scenario.

[0131] 1.1 Unified Multi-Rule Encoding Library Architecture The multi-rule encoding library adopts a three-layer structure of "object-rule type-encoded value," maintaining multiple encoding identifiers for the same business object at different levels. The metadata encoding layer and the static and dynamic data layers in the master data encoding layer all use the same multi-rule encoding library structure, but each layer uses different encoding rule algorithms according to its data characteristics and business requirements.

[0132] like Figure 2 As shown, the metadata encoding layer primarily employs composite identifier encoding, industry standards, and numerical abbreviations to standardize the encoding of abstract, conceptual data model elements. The static data layer uses UUIDs, snowflake algorithms, and industry standards to generate operation identifiers for specific business object instances. The dynamic data layer uses hash algorithms or industry standards to generate temporary codes for frequently generated business transaction records. Each data layer encoding supports switching between multiple rules and allows multiple codes to exist simultaneously for the same object.

[0133] The storage structure of the multi-rule encoding library is shown in Table 11.

[0134] Table 11. Storage structure of the multi-rule coding library

[0135] 1.2 Implementation of Master Data Multi-Encoding Mapping The metadata encoding layer, static data layer, and dynamic data layer all implement multi-encoding mapping through a multi-rule encoding library. The same data object can be configured with multiple encoding algorithms at different levels, and a primary identifier key is determined as the primary key for internal system processing. The mapping mechanism for each data layer adopts a unified architecture, distinguishing different levels through the `data_layer` field to ensure management consistency.

[0136] When a new data object is created, the system automatically executes the following process to establish a multi-encoding mapping: receiving a business request and determining the object identifier and data level; obtaining the encoding rule types supported by the data level; executing multiple encoding algorithms in parallel to generate corresponding encoding values; setting the primary identifier key according to the default rule or business specification; creating multiple records in the multi-rule encoding library to store the encodings of different algorithms; and setting all encoding statuses to valid.

[0137] During system initialization, each data layer automatically sets its primary identifier key according to default rules. For example, the composite identifier in the metadata encoding layer is the primary identifier, and the UUID in the static data layer is the primary identifier. The system supports dynamically switching the primary identifier key based on business scenario characteristics. At any given time, each object has exactly one primary identifier, ensuring data consistency. The switching mechanism includes: detecting changes in business scenarios; matching new primary identifier rules according to the rule priority matrix; updating the primary identifier field; verifying the usability of the encoding after the switch; and recording the switch log.

[0138] 1.3 Unified Mechanism for Encoding Switching The intelligent mapping and conversion engine enables dynamic switching between multiple encoding rules through a unified encoding selector component. The encoding selector employs a rule priority matrix and scenario matching algorithm to automatically select the optimal encoding based on business requirements. The encoding selector's workflow includes: receiving business requests and analyzing the target business scenario, performance requirements, and target system type; matching recommended encoding rule types according to a preset rule priority matrix; retrieving the encoding value of the corresponding rule from the multi-encoding mapping table; verifying the availability, permissions, and validity period of the encoding; and returning the selected encoding value.

[0139] The encoding selector performs scenario matching across multiple dimensions, including business scenario identifiers, performance metrics, target system characteristics, and historical usage records. The system configures corresponding rule priority matrices for different data layers. For example, the metadata encoding layer prioritizes composite identifier encoding in internal system processing scenarios and numerical abbreviations in high-frequency query scenarios; the static data layer prioritizes UUID encoding in distributed system scenarios and snowflake algorithms in time-series business scenarios; and the dynamic data layer prioritizes hash algorithms in high-frequency business scenarios. This scenario-based intelligent matching mechanism ensures the accuracy and efficiency of encoding usage across different business scenarios.

[0140] 1.4 External standards as an integration of coding rules Industry standard coding, as a special type of coding rule, is uniformly integrated into the multi-rule coding library. In the multi-coding mapping tables of the metadata coding layer and the static data layer, industry standard coding exists alongside other coding algorithms and is managed through unified rule configuration.

[0141] In the metadata encoding layer mapping table, industry standard codes (such as the IFC standard) and other encoding rules are stored and managed using the same field structure, ensuring the uniformity of the encoding rule base. This enables seamless data association and transformation with the information model under the IFC format.

[0142] 2. Cross-layer coding association and linkage mechanism 2.1 Intelligent Mechanism for Cross-Layer Collaboration The cross-layer encoding association and linkage mechanism is one of the core functions of the intelligent mapping and transformation engine. By establishing a complete association chain between metadata encoding, master data encoding, and dynamic data encoding, it achieves intelligent linkage and automatic switching across layers. This mechanism ensures that when the encoding rules or encoding values ​​of a certain layer change, the system can automatically trigger cross-layer updates, maintain the consistency of the encoding system, and avoid errors and delays caused by manual intervention.

[0143] Cross-layer linkage triggering scenarios: Scenario 1: Linked changes to metadata encoding When the encoding rules or encoding values ​​of the metadata encoding layer change, such as when encoding rules are upgraded or encoding values ​​are renamed, the system automatically executes the following linked processes: (1) Change detection: Capture encoding change events through a metadata encoding layer change listener; (2) Impact scope analysis: Query the hierarchical mapping table to obtain all related master data code and dynamic data code records; (3) Metadata reference update: Batch update the metadata encoding fields referenced in the static data layer and the dynamic data layer; (4) Mapping table update: Update the metadata_code field in the hierarchical mapping table; (5) Consistency verification: Verify whether the association relationship of each layer of coding is correct after the change; (6) Business verification: Sample verification of whether the related business functions are normal; (7) Log recording: Record change operations and related logs; Scenario 2: Master Data Encoding Change Linkage When the primary identifier key of the static data layer is switched or the encoding rule is changed, the system performs a coordinated action: (1) Primary identifier switch detection: Detect changes in the is_primary field in the static data layer; (2) Dynamic coding input source update: Update the master data coding referenced in the dynamic coding generation algorithm; (3) Mapping table update: Update the master_code field in the hierarchical mapping table; (4) Business notification: Notify relevant business systems of the primary identifier change; (5) Historical data compatibility: Maintain the mapping relationship of the old coding to support historical data query.

[0144] Scenario 3: Linkage of business scenario configuration changes When the coding rule configuration of a business scenario changes, the system automatically adjusts the dynamic coding generation rule: (1) Configuration change detection: Detect changes in the coding rule configuration of the business scenario; (2) Dynamic coding rule update: Update the algorithm configuration of the dynamic coding generator; (3) Mapping relationship reconstruction: Reconstruct the mapping relationship between the dynamic coding and the upper-layer coding according to the new rule; (4) Old mapping cleanup: Clean up expired mapping records.

[0145] Among them, the linkage processing adopts an event-driven asynchronous mechanism to ensure that the linkage operation does not affect the main business process. The system captures coding change events through a change listener, queries the hierarchical mapping table to analyze the scope of influence, batch-updates the coding references in the associated layer, updates the associated records in the mapping table, asynchronously validates data consistency, and records complete operation logs. This mechanism ensures automatic adaptation when the coding system changes, avoiding errors and delays caused by manual intervention.

[0146] 2.2 Generation and association of dynamic coding Dynamic coding is a temporary coding generated for high-frequency business transaction records, featuring light weight, temporariness, and high performance. The generation of dynamic coding uses the upper-layer coding as the input source, and forms a complete coding traceability chain by establishing an association relationship with the upper-layer coding.

[0147] The generation of dynamic coding requires combining multiple input elements, including business scenario coding, target master data coding, timestamp, and random number, etc. After the system combines these elements according to a predetermined rule, it generates a fixed-length coding string through a specific algorithm. The generated dynamic coding establishes an association relationship with the upper-layer coding in the hierarchical mapping table, recording information such as mapping type, effective time, and expiration time.

[0148] Dynamic codes have a clearly defined lifespan and usage limitations. The system sets the validity period for dynamic codes based on the business scenario, such as 24 hours for routine inspections and 2 hours for temporary access tokens. Simultaneously, dynamic codes can be configured with a maximum number of uses; high-security scenarios limit them to single use, while general business scenarios allow for multiple uses. The system manages the lifecycle of dynamic codes through status fields, including valid, invalid, and expired states.

[0149] When a business system uses dynamic encoding, the system queries a hierarchical mapping table to parse out the associated master data encoding and metadata encoding, thus reconstructing the complete business context. This mechanism allows the business system to complete business operations without needing to concern itself with the complex relationships between the underlying encodings, only needing to process the simplified dynamic encoding.

[0150] After the lifecycle of dynamically encoded data ends, the system automatically cleans up expired mapping records and releases storage space. This temporary design ensures both the efficiency of business processing and the cleanliness of the system's data.

[0151] Step S4: Obtain traffic business data and encode the traffic business data through the metadata encoding layer and the master data encoding layer.

[0152] In the aforementioned metadata encoding layer and master data encoding layer, any traffic business data is encoded and stored as encoded data according to the corresponding logic of the encoding layer.

[0153] Step S5: When a data request containing temporary dynamic encoding is received, the mapping relationship is queried through the intelligent mapping and conversion engine to parse out the corresponding static primary key, metadata encoding and business scenario.

[0154] Step S6: When interaction with external systems is required, the metadata encoding is mapped to the target encoding that conforms to the external standard through the intelligent mapping and conversion engine for output.

[0155] This includes mapping metadata encoding to a target encoding conforming to external standards for output, including: Identify the external coding standard used by the target system; Query the preset encoding mapping table to map the metadata encoding to the encoding value under the external encoding standard; The data is assembled and output according to the data format of the external encoding standard.

[0156] The implementation of steps S5 and S6 can be carried out by referring to the relevant description of the preceding construction steps.

[0157] In summary, this embodiment uses two typical business scenarios—tunnel asset management and daily inspection—as examples to fully demonstrate the specific application process of the intelligent coding system in actual business operations. Through the detailed explanation of these two scenarios, the technical advantages and implementation effects of this invention in solving practical business problems can be clearly demonstrated.

[0158] 1. Asset Management Business Scenarios In the context of tunnel asset management, this invention achieves precise management and efficient data processing throughout the entire lifecycle of tunnel assets through the collaborative operation of a multi-level coding system. This scenario covers the complete business process from asset registration and information management to data exchange.

[0159] (1) Asset registration and coding generation stage When the newly constructed tunnel asset "Nanshan Tunnel" needs to be digitally registered, the system first defines the concept at the metadata layer. The metadata encoding layer assigns the identifier code ENT_TNL_0001 to the "tunnel" entity and the scenario code SCENE_ASM_0001 to the asset management business scenario. Subsequently, the system automatically establishes the data element DE_TNL_ASM_0001 and the data model DM_TNL_ASM_0001 according to business requirements, forming a complete metadata definition system.

[0160] After the metadata definition is completed, the system enters the master data encoding generation phase. A unique static identifier code is generated for the "Nanshan Tunnel" instance in the master data layer. Based on the configured multi-encoding rules, the system generates three types of codes in parallel: a master identifier code (e.g., A3F9B7C2...C5) using the SUC-32 algorithm, a distributed system identification code using the UUID algorithm, and encoding rules conforming to industry standards. These three codes are stored in a multi-rule encoding library, with the SUC-32 code marked as the master identifier, serving as the primary basis for internal system processing.

[0161] (2) Asset Information Management Stage During asset information management, the system intelligently selects the encoding type based on different business needs. When performing internal data governance, the system defaults to using the SUC-32 master identifier code to ensure processing efficiency and data consistency. When exchanging data with distributed systems, the system automatically switches to UUID encoding to guarantee unique identification across systems. When interfacing with external regulatory systems, the system dynamically converts to industry standard encoding to ensure compliance with industry specifications.

[0162] The intelligent mapping and transformation engine maintains a complete mapping relationship between metadata encoding and master data encoding. When any encoding changes, the system automatically triggers a linked update. For example, when metadata encoding needs to be adjusted due to business specification upgrades, the intelligent mapping and transformation engine will automatically update the reference relationships of all associated master data encodings to ensure business continuity.

[0163] (3) Data exchange and integration stage In data exchange scenarios, the system demonstrates strong compatibility. When the BIM system needs to obtain tunnel information, the intelligent mapping and conversion engine identifies that the target system requires the IFC standard, automatically converts the internal code ENT_TNL_0001 to IfcTunnel, and assembles the data according to the IFC standard format. This dynamic conversion mechanism ensures seamless integration with different standard systems, effectively solving the problem of data silos.

[0164] 2. Routine patrol business scenarios The routine inspection scenario demonstrates the advantages of this invention in processing high-frequency, real-time business data. This scenario highlights the lightweight, temporary, and efficient characteristics of dynamic coding.

[0165] (1) Patrol mission initiation phase When an inspector begins a routine inspection, the system first identifies the business scenario. It confirms the current task as a routine inspection using the business scenario code SCENE_RIN_0001 and associates it with the corresponding data model DM_TNL_RIN_0001. Based on the inspector's selected inspection target, "Nanshan Tunnel," the system retrieves its master data codes A3F9B7C2...C5.

[0166] Based on this, the system initiates a dynamic encoding generation process. The generation process includes three key steps: input element combination, hash calculation, and encoding truncation. The system combines the business scenario encoding, target static encoding, current timestamp, and random number according to predetermined rules to form a standardized input string. Then, the SHA-256 hash algorithm is used to calculate a 256-bit hash value, and finally, the first 8 characters are truncated as the dynamic encoding, such as 8B3D1E4F.

[0167] (2) Patrol data collection stage During the inspection, the mobile inspection app uses dynamic encoding 8B3D1E4F for data collection and transmission. Because the dynamic encoding is only 8 bits long, it greatly reduces network transmission overhead. When inspectors record data on tunnel lining cracks, the system automatically binds the dynamic encoding to the inspection data, forming a complete data packet.

[0168] Dynamic encoding acts as a temporary token at this stage. The system maintains the association between encodings and business contexts through a dynamic encoding mapping table, including attributes such as associated static encodings, business scenarios, generation time, validity period, and maximum number of uses. This design ensures both the accuracy of data association and system security through lifecycle management.

[0169] (3) Data submission and processing stage When an inspector submits inspection data, the system quickly reconstructs the complete business context through a dynamic encoding parsing mechanism. The submitted data packet contains only a lightweight dynamic encoding 8B3D1E4F. By querying the dynamic encoding mapping table, the system parses out the associated static encoding A3F9B7C2...C5 and the business scenario SCENE_RIN_0001, thereby obtaining the complete asset information and inspection business rules for "Nanshan Tunnel".

[0170] During data processing, the system updates the usage status of dynamic codes, including incrementing the current usage count and recording the last usage time. When the usage count reaches the limit or the validity period expires, the system automatically marks the code as invalid, ensuring the one-time or short-term use characteristic of the code.

[0171] (4) Business Collaboration and Data Integration Phase In routine inspection operations, this invention supports multi-system collaboration. Mobile inspection apps, back-end management systems, BIM systems, and other systems can exchange data through a unified dynamic coding mechanism. When a major hazard is discovered during an inspection and a maintenance process needs to be initiated, the system directly links to asset information through dynamic coding, automatically generates a maintenance work order, and triggers the corresponding business process.

[0172] The temporary nature of dynamic coding is evident in this scenario. After the inspection task is completed, the relevant dynamic codes automatically enter the expiration process, and the system periodically cleans up expired coding records. This mechanism ensures the complete traceability of business data while avoiding long-term occupation of system resources.

[0173] 3. Cross-scenario collaborative applications In practice, asset management and routine inspection are closely related business scenarios. This invention achieves seamless connection between the scenarios through an intelligent mapping mechanism.

[0174] (1) Data association and traceability When anomalies are detected in tunnel assets during routine inspections, the system quickly locates the specific asset instance through the correlation between dynamic and static codes and retrieves the asset's complete historical data. Simultaneously, the inspection results are automatically updated to the asset status information, forming a closed-loop management system.

[0175] (2) Business process linkage The asset data model defined in the asset management business scenario provides a standardized data template for daily inspections. The data accumulated during these daily inspections, in turn, provides data support for asset condition assessment and maintenance decisions. The two scenarios achieve data sharing and business collaboration through a unified coding system.

[0176] (3) Performance optimization In practical applications, the coding system of this invention exhibits significant performance advantages. In terms of data storage, the separation of static and dynamic data reduces redundant storage; in terms of data transmission, the lightweight nature of dynamic coding reduces network load; and in terms of data processing, intelligent parsing and conversion of the encoded data improves system response speed.

[0177] In summary, the technical effects of this invention are as follows: I. Systematically solve the data silo problem and achieve cross-standard interoperability. This invention constructs a two-layer intelligent coding system that coordinates the metadata coding layer and the master data coding layer, and formally defines and uniformly codes entities, attributes, relationships, and business scenarios. It assigns permanent and unique identifiers to static core assets and generates temporary lightweight codes for dynamic business flows. At the same time, it uses an intelligent mapping and conversion engine to dynamically convert internal codes into target codes that conform to external standards such as IFC and OmniClass. This breaks through the current dilemma of numerous and incompatible classification and coding standards, eliminates the interaction barriers between roadside facility data and vehicle operation data, and between different business systems, and achieves full-chain business collaboration without the need to establish complex and fragile manual mapping rules.

[0178] II. Significantly reduce inter-machine interaction overhead and improve system real-time performance. This invention employs temporary dynamic encoding based on a hash algorithm for dynamic business flows. It generates a fixed-length short string using the current business scenario code, the target static primary key, a timestamp, and a random number as input elements. This encoding is only valid within its respective business scenario context, has a short lifespan, and can be used up to a set limit. Compared to the lengthy encoding of reused static assets or the traditional method of using another set of cumbersome rules, the dynamic encoding of this invention significantly reduces the transmission, serialization, and storage overhead in high-concurrency, low-latency automated machine-to-machine interaction scenarios such as microservice interfaces, V2X communication in the Internet of Vehicles, and edge computing. This effectively alleviates resource waste throughout the entire chain from generation and maintenance to use, meeting the high-efficiency operation requirements of real-time intelligent transportation services.

[0179] Third, achieve refined management by separating static and dynamic data to ensure data governance and traceability. This invention separates static core assets from dynamic business processes and maintains the mapping relationship between dynamic encoding and static primary keys, metadata encoding, and business scenarios through an intelligent mapping and transformation engine. It also automatically manages the validity period, usage count, and expiration status of encodings. This dynamic-static separation design ensures the stability and traceability of static assets throughout their entire lifecycle while avoiding the long-term occupation of system resources by dynamic data, achieving on-demand allocation and efficient utilization of encoding resources.

[0180] IV. Provides a scalable unified semantic framework to support rapid integration of new business applications. This invention standardizes the definition of entities, attributes, relationships, and business scenarios through a metadata encoding layer, allowing for the expansion of data elements and data models. It also constructs a multi-rule encoding library, storing multiple encoded values ​​under various encoding rules for the same object. This supports dynamic switching of the primary identifier key based on business scenarios and can integrate industry standard encodings as one of the rules. This enables the encoding system of this invention to be aware of business scenario context, adapt to different encoding rules, and quickly respond to the access needs of new facilities or new business scenarios, without requiring a lengthy standardization process. This provides core support for building an efficient and unified intelligent transportation data foundation.

[0181] Example 2 Please refer to Figure 10 A dynamic perception coding and conversion system 1 for traffic business scenarios includes a memory 3, a processor 2, and a computer program stored in the memory 3 and run on the processor 2. When the processor 2 executes the computer program, it implements the steps in Embodiment 1 or 2 above.

[0182] Since the systems / devices described in the above embodiments of the present invention are systems / devices used to implement the methods of the above embodiments of the present invention, those skilled in the art can understand the specific structure and modifications of the systems / devices based on the methods described in the above embodiments of the present invention, and therefore will not be repeated here. All systems / devices used in the methods of the above embodiments of the present invention fall within the scope of protection of the present invention.

[0183] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0184] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (devices), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions.

[0185] It should be noted that any reference numerals placed between parentheses in the claims should not be construed as limiting the claims. The word "comprising" does not exclude the presence of components or steps not listed in the claims. The word "a" or "an" preceding a component does not exclude the presence of a plurality of such components. The invention can be implemented by means of hardware comprising several different components and by means of a suitably programmed computer. In claims that enumerate several means, several of these means may be embodied by the same hardware. The use of the terms first, second, third, etc., is merely for convenience of expression and does not indicate any order. These terms can be understood as part of the component names.

[0186] Furthermore, it should be noted that in the description of this specification, the terms "one embodiment," "some embodiments," "embodiment," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0187] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the claims should be interpreted to include both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0188] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, then this invention should also include these modifications and variations.

Claims

1. A dynamic sensing encoding and conversion method for traffic business scenarios, characterized in that, include: Step S1: Construct a metadata encoding layer, formally define multiple metadata elements in the transportation field, and generate a globally unique metadata code for each metadata element. The metadata elements include at least entities, attributes, relationships, and business scenarios. Step S2: Construct the master data encoding layer. Based on the metadata encoding, generate a permanently unique static primary key for static business data objects and generate a temporary dynamic code for dynamic business processes. The temporary dynamic code is generated with business scenario code, static primary key, timestamp and random number as input parameters. Step S3: Construct an intelligent mapping and transformation engine to establish a mapping relationship between the temporary dynamic code and the static primary key, the metadata code, and the business scenario; Step S4: Obtain traffic business data and encode the traffic business data through the metadata encoding layer and the master data encoding layer; Step S5: When a data request containing temporary dynamic encoding is received, the mapping relationship is queried through the intelligent mapping and conversion engine to parse out the corresponding static primary key, metadata encoding and business scenario; Step S6: When interaction with external systems is required, the metadata encoding is mapped to a target encoding that conforms to external standards and output through the intelligent mapping and conversion engine.

2. The dynamic perception coding and conversion method for traffic business scenarios according to claim 1, characterized in that, The metadata encoding layer also defines data elements and / or data models. The data element is the smallest data unit formed by the association of entities, attributes and business scenarios. The data model is a data structure template composed of multiple data elements according to preset rules.

3. The dynamic perception coding and conversion method for traffic business scenarios according to claim 2, characterized in that, The temporary dynamic code is set with an expiration period and a maximum number of uses. After each use, the number of uses and the last use time of the temporary dynamic code are updated. When the current usage count reaches the maximum usage count or the current time exceeds the validity period, the temporary dynamic code will be automatically marked as invalid.

4. The dynamic perception coding and conversion method for traffic business scenarios according to claim 1, characterized in that, Step S3 further includes: Build a multi-rule encoding library to store multiple encoded values ​​under multiple encoding rules for the same metadata object or the same static primary key object, and specify one of them as the primary identifier key; The primary identifier key is dynamically switched when a change in business scenario is detected, and the multi-rule encoding library supports using industry standard encoding as one of the encoding rules to achieve dynamic mapping with external standards.

5. A dynamic perception coding and conversion method for traffic business scenarios according to claim 4, characterized in that, Also includes: When the metadata encoding changes, the fields referencing that metadata encoding in the mapping relationship between the static primary key and the temporary dynamic encoding are automatically updated; When the primary identifier key of the static primary key changes, the static primary key value referenced in the temporary dynamic encoding generation algorithm is automatically updated.

6. The dynamic perception coding and conversion method for traffic business scenarios according to claim 1, characterized in that, The metadata encoding is mapped to a target encoding conforming to external standards for output, including: Identify the external coding standard used by the target system; Query the preset encoding mapping table and map the metadata encoding to the encoding value under the external encoding standard; The data is assembled and output according to the data format of the external encoding standard.

7. A dynamic perception coding and conversion method for traffic business scenarios according to claim 3, characterized in that, Also includes: Record the lifecycle status of each temporary dynamic code; The system automatically manages the validity, invalidation, or expiration status of temporary dynamic codes by using the status fields, generation time, expiration time, maximum number of uses, and current number of uses in the mapping table.

8. A dynamic perception coding and conversion method for traffic business scenarios according to claim 4, characterized in that, Also includes: Record the mapping relationship between object identifier, data level, encoding rule type, encoding value, and whether it is the main identifier to the multi-rule encoding library; When a new business scenario or data standard is detected, the encoding rule types in the multi-rule encoding library are automatically added or updated.

9. A dynamic perception coding and conversion method for traffic business scenarios according to any one of claims 1 to 8, characterized in that, The static primary key is a globally unique permanent identifier that is not embedded in business semantics. The temporary dynamic code is only valid within the context of its business scenario and will automatically expire when the session ends or the preset number of uses is reached.

10. A dynamic perception encoding and conversion system for traffic business scenarios, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the dynamic perception encoding and conversion method for traffic business scenarios as described in any one of claims 1 to 9.

Images