Communication matrix verification and repair method, system, electronic device and medium

Abstract

The application provides a communication matrix checking and repairing method, system, electronic equipment and medium, and belongs to the technical field of vehicles.The method comprises the following steps: obtaining a preset structured rule library, and constructing a rule knowledge graph based on the preset structured rule library; performing multi-stage rule checking on an enhanced whole vehicle communication matrix based on the rule knowledge graph, and obtaining a rule checking result; generating a comprehensive error report according to the rule checking result and an abnormality detection result, and extracting an automatic repair type problem in the comprehensive error report; performing a repair operation on the automatic repair type problem according to a repair template, so as to update the enhanced whole vehicle communication matrix, obtain a target whole vehicle communication matrix, and generate a change record. In the application, the configurable rule library structure realizes flexible configuration and differentiated control of checking rules, multi-stage rule checking and abnormality detection are introduced, the consistency and reliability of the checking result are improved, the classification automatic repair strategy realizes standardized and automatic repair of common errors, and the repair efficiency and repair quality are improved.

Description

Technical Field

[0001] This invention relates to the field of vehicle technology, and in particular to a communication matrix verification and repair method, system, electronic device, and medium. Background Technology

[0002] In the iterative development of automotive CAN / CAN FD communication matrices, the matrices need to meet numerous verification rules, such as naming conventions, value ranges, and logical consistency. However, related technologies suffer from problems such as tight coupling between rules and code, making flexible configuration impossible; fuzzy rules cannot be precisely expressed, relying on manual judgment; version difference analysis relies on manual comparison, resulting in missing change history; and bug fixing depends on personal experience, lacking standardized processes. Summary of the Invention

[0003] The present invention aims to solve at least one of the technical problems existing in the prior art, and proposes a communication matrix verification and repair method, system, electronic device and medium.

[0004] In a first aspect, embodiments of the present invention provide a communication matrix verification and repair method, comprising:

[0005] Obtain a preset structured rule base, and construct a rule knowledge graph based on the preset structured rule base;

[0006] Based on the rule knowledge graph, a multi-stage rule verification is performed on the enhanced vehicle communication matrix to obtain the rule verification results;

[0007] A comprehensive error report is generated based on the rule verification results and anomaly detection results, and automatic repair issues are extracted from the comprehensive error report.

[0008] The automatic repair operation is performed on the problem according to the repair template to update the enhanced vehicle communication matrix, obtain the target vehicle communication matrix, and generate a change history.

[0009] In some embodiments, obtaining a preset structured rule base and constructing a rule knowledge graph based on the preset structured rule base includes:

[0010] Obtain a preset structured rule base; wherein each rule in the preset structured rule base includes metadata for describing attributes, and the metadata includes severity level and remediation template;

[0011] A rule knowledge graph is constructed using the rules in the preset structured rule base as entity nodes and the dependencies between rules in the preset structured rule base as edges.

[0012] In some embodiments, the step of performing multi-stage rule verification on the enhanced vehicle communication matrix based on the rule knowledge graph to obtain rule verification results includes:

[0013] Obtain the enhanced vehicle communication matrix to be verified as the current communication matrix model;

[0014] Based on the rule knowledge graph, the current communication matrix model is sequentially subjected to independent rule verification, dependent rule verification, and global consistency verification to obtain rule verification results. The independent rule verification includes performing format checks and value range checks; the dependent rule verification includes executing rule chains with dependencies based on topology order; and the global consistency verification includes performing cross-table association rules and network segment load rate checks.

[0015] In some embodiments, generating a comprehensive error report based on the rule verification results and anomaly detection results, and extracting automatically repairable issues from the comprehensive error report, includes:

[0016] For the fuzzy rules in the preset structured rule base, anomaly detection is performed on the current communication matrix model based on a machine learning model to obtain anomaly detection results;

[0017] By combining the rule verification results and anomaly detection results, a comprehensive error report is generated.

[0018] Based on the rule knowledge graph, the root cause of the error information in the comprehensive error report is traced, and the problem is divided into automatic repair problems and non-automatic repair problems according to the severity level and repair template.

[0019] In some embodiments, the step of performing repair operations on the automatically repaired issues according to the repair template to update the enhanced vehicle communication matrix, obtain the target vehicle communication matrix, and generate a change history includes:

[0020] The historical communication matrix is ​​used as the baseline communication matrix model, and the enhanced vehicle communication matrix to be verified is used as the current communication matrix model.

[0021] The repair template is used to automatically perform repair operations on the automatic repair type of problems in order to update the current communication matrix model;

[0022] After the current communication matrix model is repaired, the updated current communication matrix model is compared with the baseline communication matrix model to generate a change history.

[0023] In some embodiments, the method further includes:

[0024] Obtain the candidate scheme set of incremental matrix based on atomic operation analysis;

[0025] Real-time verification and conflict arbitration are performed on the candidate scheme set of the incremental matrix to obtain the target incremental matrix;

[0026] The target incremental matrix is ​​integrated with the original communication matrix to generate the initial vehicle communication matrix;

[0027] Based on the network topology model, physical routing planning is performed on the initial vehicle communication matrix to generate an enhanced vehicle communication matrix.

[0028] In some embodiments, the method further includes:

[0029] Obtain the network segment and node configuration table and the gateway node configuration table;

[0030] Obtain the custom configuration splitting rules, and determine the splitting dimensions based on the custom configuration splitting rules;

[0031] Based on the splitting dimensions and combined with the network segment and node configuration table and the gateway node configuration table, the target vehicle communication matrix is ​​split in multiple dimensions to obtain the split sub-matrix file;

[0032] The split sub-matrix files are converted into target format files and then distributed.

[0033] Secondly, embodiments of the present invention provide a communication matrix verification and repair system, comprising:

[0034] The rule base acquisition module is used to acquire a preset structured rule base and construct a rule knowledge graph based on the preset structured rule base;

[0035] The rule verification module is used to perform multi-stage rule verification on the enhanced vehicle communication matrix based on the rule knowledge graph, and obtain the rule verification result;

[0036] The results fusion and reporting module is used to generate a comprehensive error report based on the rule verification results and anomaly detection results, and to extract automatic repair issues from the comprehensive error report.

[0037] The automatic repair module is used to perform repair operations on the automatic repair type of problems according to the repair template, so as to update the enhanced vehicle communication matrix to obtain the target vehicle communication matrix and generate a change history.

[0038] Thirdly, embodiments of the present invention provide an electronic device, including:

[0039] One or more processors;

[0040] Memory, used to store one or more programs;

[0041] When the one or more programs are executed by the one or more processors, the one or more processors implement any of the methods described above.

[0042] Fourthly, embodiments of the present invention provide a computer-readable medium on which a computer program is stored, the computer program being executed by a processor to implement the steps of any of the methods described above.

[0043] The communication matrix verification and repair method provided by this invention includes: acquiring a preset structured rule base; constructing a rule knowledge graph based on the preset structured rule base; performing multi-stage rule verification on an enhanced vehicle communication matrix based on the rule knowledge graph to obtain rule verification results; generating a comprehensive error report based on the rule verification results and anomaly detection results, and extracting automatic repair issues from the comprehensive error report; performing repair operations on the automatic repair issues according to a repair template to update the enhanced vehicle communication matrix, obtain a target vehicle communication matrix, and generate a change history. This invention achieves flexible configuration and differentiated management of verification rules through a configurable rule base structure, allowing for rapid adjustment of rule parameters across different projects without modifying program code, significantly reducing the complexity of multi-project maintenance. The introduction of multi-stage rule verification and anomaly detection avoids subjective differences in manual review, improving the consistency and reliability of verification results. The adoption of a classification-based automatic repair strategy based on repair templates enables standardized and automated repair of common errors, significantly improving repair efficiency and quality. Automatic version comparison generates change history, avoiding omissions and errors that may occur during manual comparison. The automatically generated, uniformly formatted change history provides a reliable, complete, and traceable version history for the iterative development of the communication matrix, greatly improving the informatization level of version management. Attached Figure Description

[0044] Figure 1 A flowchart illustrating a communication matrix verification and repair method provided in an embodiment of the present invention;

[0045] Figure 2 This is a flowchart illustrating an optional specific implementation method involved in an embodiment of the present invention;

[0046] Figure 3 This is a schematic diagram of an implementation example process involved in the embodiments of the present invention;

[0047] Figure 4 A structural block diagram of a communication matrix verification and repair system provided in an embodiment of the present invention;

[0048] Figure 5 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0049] To enable those skilled in the art to better understand the technical solutions of the present invention, exemplary embodiments of the present invention are described below in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0050] Where there is no conflict, the various embodiments of the present invention and the features thereof may be combined with each other.

[0051] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0052] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0053] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having the meaning consistent with their meaning in the context of the relevant art and the invention, and will not be interpreted as having an idealized or overly formal meaning unless expressly so defined herein.

[0054] In the technical solution of this invention, the collection, storage, use, processing, transmission, provision, and disclosure of user personal information all comply with relevant laws and regulations and do not violate public order and good morals. The use of user data in this technical solution follows relevant national laws and regulations (e.g., the "Information Security Technology - Personal Information Security Specification"). For example: appropriate measures are taken for personal information access control; restrictions are imposed on the display of personal information; the purpose of using personal information does not exceed the scope of direct or reasonable association; and explicit identity targeting is eliminated when using personal information to avoid precisely locating a specific individual.

[0055] The key terms involved in this invention are defined as follows:

[0056] CAN / CAN FD: Controller Area Network, vehicle-mounted controller area network.

[0057] In related technologies, rules and code are tightly coupled, lacking flexible configuration. Rules are fixed in the code, making modification difficult. Parameters (such as name length and message type) cannot be dynamically adjusted across different projects, requiring the maintenance of multiple scripts. There is a lack of differentiation in rule severity levels, hindering a flexible management mechanism that allows for mandatory activation of core rules and optional configuration of normative rules. Fuzzy rules cannot be precisely expressed, relying on manual judgment. Rules such as "complete value description" and "comprehensive enumeration value coverage" cannot be quantified, requiring manual review, which is inefficient and highly subjective. Version difference analysis relies on manual comparison, with missing change logs. Engineers must manually compare Excel version differences, resulting in a large workload and a high risk of omissions. Change logs are manually filled out, leading to incomplete records and inconsistent formats. Error fixing relies on personal experience, lacking standardized processes. Tools in related technologies only report errors without providing repair guidance, leading to repeated occurrences of the same errors and inconsistent repair quality. Pure rule engines cannot handle fuzzy scenarios, while pure AI black boxes lack interpretability and determinism. The two fail to collaborate, resulting in a disconnect between rules and AI, preventing them from complementing each other's strengths.

[0058] Therefore, there is an urgent need for an intelligent verification method that combines rules and AI to achieve a complete solution that enables configurable rules, quantifiable fuzzy rules, automated version differences, and self-correcting errors.

[0059] To address at least one of the technical problems existing in the aforementioned related technologies, the present invention provides a communication matrix verification and repair method. Figure 1 This is a flowchart illustrating a communication matrix verification and repair method provided in an embodiment of the present invention.

[0060] As one embodiment of the present invention, such as Figure 1 As shown, the communication matrix verification and repair method includes:

[0061] Step S1: Obtain a preset structured rule base and construct a rule knowledge graph based on the preset structured rule base;

[0062] Step S2: Perform multi-stage rule verification on the enhanced vehicle communication matrix based on the rule knowledge graph to obtain the rule verification results;

[0063] Step S3: Generate a comprehensive error report based on the rule verification results and anomaly detection results, and extract the automatic repair issues from the comprehensive error report;

[0064] Step S4: Perform repair operations on the automatic repair type of problems according to the repair template to update the enhanced vehicle communication matrix, obtain the target vehicle communication matrix, and generate a change history.

[0065] It should be noted that the execution subject in this embodiment can be an electronic device, which can be a computer device with data processing function, or other devices that can achieve the same or similar functions. This embodiment does not limit this. In this embodiment, the execution subject is a computer device as an example for explanation.

[0066] Specifically, this embodiment of the method is applicable to the fields of automotive electronic and electrical architecture design and vehicle network communication. It employs a rule-based and AI-driven approach to intelligently verify, self-repair, and automatically generate version history for onboard CAN / CAN FD communication matrices. This method is used to intelligently compare versions, automatically generate change histories, perform rule verification, anomaly detection, root cause analysis, automatic repair, and quality optimization of communication matrices (such as enhanced vehicle communication matrices) generated during the forward design process. The core of this method lies in constructing a configurable signal matrix verification rule base. Through rule-based and AI collaboration, the current version is verified and repaired, and a change history is automatically generated upon verification.

[0067] For example, intelligent verification, automatic repair, and final matrix generation are performed. The enhanced vehicle communication matrix is ​​submitted to the intelligent verification system (running the method of this embodiment), which utilizes rule and AI collaborative technology for automated verification, anomaly detection, and self-repair. The matrix is ​​comprehensively checked according to a preset rule base (including error levels and warning levels), automatically repairing problems that can be automatically fixed, generating interactive suggestions for complex problems, and finally generating a final version of the vehicle communication matrix (i.e., the target vehicle communication matrix) that meets quality requirements, and automatically outputting the version change history. The following describes the specific steps.

[0068] In some embodiments, obtaining a preset structured rule base and constructing a rule knowledge graph based on the preset structured rule base includes: obtaining a preset structured rule base; wherein each rule in the preset structured rule base includes metadata for describing attributes, the metadata including severity level and remediation template; and constructing a rule knowledge graph using the rules in the preset structured rule base as entity nodes and the dependencies between rules in the preset structured rule base as edges.

[0069] Specifically, such as Figure 2As shown, the configurable rule base acquisition and structured parsing are supported. A built-in pre-organized structured default rule base (pre-defined structured rule base) based on enterprise specifications is included. Each rule contains complete metadata such as rule ID, rule type, inspection object, constraints, judgment logic, severity level, repair template, and dependencies. Rules in the default rule base (pre-defined structured rule base) that are strongly related to DBC generation (e.g., message ID uniqueness, message length compliance, signal layout non-conflict, physical value calculation correctness) are set to error level; other normative rules (e.g., naming conventions, value description completeness, enumeration value coverage) are set to warning level. The default rules support customized configuration for each vehicle model project, forming a vehicle-specific rule base, including: parameter threshold adjustment, custom message type whitelist, and rule enabling / disabling.

[0070] For example, parameter threshold adjustment: Modify parameters such as character length limit, ID range, and load rate threshold according to project requirements (parameter values ​​are configurable, but the verification logic remains unchanged): For example, the maximum length of the node name is N characters, with the default being N=32; the ID range for each period (e.g., the range of packet IDs in a 10ms period is 0x1F~0xFF); the load rate threshold for each network segment (default 55%). If there are special requirements, these can be adjusted in the configuration interface.

[0071] For example, the message type whitelist can be customized: the default message types are "Normal (application message), NM (network management message), Diag (diagnostic message)", and custom types can be added. The relevant rules will automatically update the whitelist.

[0072] For example, rule enabling / disabling: Projects can enable or disable warning level rules (such as naming conventions, value description integrity, etc.) as needed, while error level rules (such as message ID uniqueness, signal arrangement non-conflict, etc.) are mandatory to be enabled and cannot be disabled, to ensure the basic validity of DBC generation.

[0073] Specifically, such as Figure 2 As shown, a rule knowledge graph is constructed. Each rule is treated as an entity node in the graph, and the references, dependencies, and mutual exclusions between rules are used as edges to construct a rule knowledge graph, which is used to optimize the rule execution order and conflict detection.

[0074] In this embodiment, a configurable rule base structure and a severity level attribute are introduced to enable flexible configuration and differentiated management of validation rules. Rule parameters can be quickly adjusted across different projects without modifying program code, significantly reducing the complexity of maintaining multiple projects. Simultaneously, core rules are enforced while allowing users to customize non-core rules. This ensures the basic validity of the DBC file (i.e., meets the core mandatory rules) while acknowledging differentiated specification requirements between projects, achieving a balance between adaptability and determinism.

[0075] In some embodiments, multi-stage rule verification is performed on the enhanced vehicle communication matrix based on the rule knowledge graph to obtain rule verification results, including: obtaining the enhanced vehicle communication matrix to be verified as the current communication matrix model; performing independent rule verification, dependent rule verification, and global consistency verification on the current communication matrix model in sequence based on the rule knowledge graph to obtain rule verification results; wherein, the independent rule verification includes performing format checks and value range checks, the dependent rule verification includes performing rule chains with dependencies based on topological order, and the global consistency verification includes performing cross-table association rules and network segment load rate checks.

[0076] In some embodiments, a comprehensive error report is generated based on the rule verification results and anomaly detection results, and automatic repair issues are extracted from the comprehensive error report, including: for fuzzy rules in the preset structured rule base, performing anomaly detection on the current communication matrix model based on a machine learning model to obtain anomaly detection results; fusing the rule verification results and anomaly detection results to generate a comprehensive error report; tracing the root cause of errors in the comprehensive error report based on the rule knowledge graph, and classifying the issues into automatic repair issues and non-automatic repair issues according to the severity level and repair template.

[0077] Specifically, such as Figure 2 As shown, the communication matrix model is constructed. The historical version matrix is ​​constructed as the baseline communication matrix model, and the current matrix to be verified (enhanced vehicle communication matrix) is constructed as the current communication matrix model. The ECU, messages, signals and their attributes, and send / receive relationships are stored in a structured form.

[0078] For example, such as Figure 2 As shown, multi-stage rule validation and fuzzy rule anomaly detection are implemented. Based on a rule knowledge graph, the current matrix undergoes three-stage validation: independent rule validation (e.g., format checking, naming conventions, value range validation); dependent rule validation (e.g., executing rule chains in topological order, including message-signal consistency validation, sender-receiver node matching validation, and logical relationship validation between message and signal sending types); and global consistency validation (e.g., cross-table association rules, such as gateway node list and vehicle model information consistency validation, gateway route reachability validation, and network segment load rate validation). For fuzzy rules (e.g., enumerated value coverage integrity), machine learning models can be used for anomaly detection, outputting anomaly probabilities and suspicious locations.

[0079] Specifically, such as Figure 2As shown, the results are integrated into a comprehensive error report. The report combines rule validation and AI detection results, generating a comprehensive error report. Each error / warning includes a detailed description and cell location (worksheet, row number, column name). Example errors include: incomplete enumeration values, duplicate invalid and enumeration values, enumeration values ​​exceeding the signal length range, missing gateway nodes, logical conflicts between message transmission type and signal transmission type, invalid signal values, incorrect initial values, mismatch between bus and physical values, and missing routing transceiver tags.

[0080] For example, such as Figure 2 As shown, root cause analysis and problem classification are performed. The root cause of the problem is traced through the rule dependency graph, and the problems are divided into AI-repairable problems (automatically repairable problems) and manually confirmed problems (non-automatically repairable problems) according to the severity level and repair template.

[0081] In this embodiment, a machine learning model is introduced for fuzzy rule anomaly detection, enabling the quantification and objective judgment of fuzzy rules. For fuzzy rules such as the completeness of enumerated value coverage, which cannot be quantified by precise formulas, a pre-trained machine learning model can be used to detect anomalies in the data corresponding to the objects being checked in the current matrix, outputting anomaly probabilities and suspicious locations. This transforms the judgment of fuzzy rules from subjective human experience to model-based quantitative analysis, achieving objective identification of potential anomalies. This embodiment transforms the original fuzzy rule judgment process, which relied on human experience and had a certain degree of subjectivity, into quantifiable anomaly probability values ​​output by the model. This avoids the subjective differences of manual review, improves the consistency and reliability of verification results, and reduces the workload of manual review.

[0082] In some embodiments, performing a repair operation on the automatically repairable issues according to a repair template to update the enhanced vehicle communication matrix to obtain the target vehicle communication matrix and generate a change history includes: obtaining a historical communication matrix as a baseline communication matrix model, and using the enhanced vehicle communication matrix to be verified as the current communication matrix model; automatically performing a repair operation on the automatically repairable issues according to the repair template to update the current communication matrix model; and after performing the repair on the current communication matrix model, comparing the updated current communication matrix model with the baseline communication matrix model to generate a change history.

[0083] Specifically, such as Figure 2As shown, intelligent repair is implemented. For AI-automated repair issues (automatic repair issues), repair operations can be automatically performed based on the repair template in the rule metadata. Specifically, these include: for issues with invalid signal values, the automatic repair logic can automatically correct the invalid value to the maximum bus value; for issues with incorrect initial signal values, the automatic repair logic can automatically correct the initial value to 0; for issues with bus value / physical value mismatch, the automatic repair logic can recalculate the bus value based on precision and offset; for issues with missing route transmit / receive tags, the automatic repair logic can automatically supplement the gateway port tag based on the route path; for issues with incomplete enumeration value descriptions, the automatic repair logic can supplement the missing enumeration item based on the signal length; and for issues with signal transmission type conflicts, the automatic repair logic can adjust the signal transmission type to match the message type. After repair, incremental rule verification is triggered, only re-verifying the affected rules.

[0084] For example, such as Figure 2 As shown, secondary verification and version comparison are performed. After repair, verification is repeated until no errors are found. Then, the current matrix (enhanced vehicle communication matrix) is automatically compared with the baseline matrix (historical version matrix), differences are identified (added / modified / deleted), a structured change history is generated, and the sender and receiver of each signal are clearly identified (including cross-network segments).

[0085] Specifically, such as Figure 2 As shown, the intelligent report is generated. The final report is output, including rule statistics, error / warning distribution, repair history, change history, and cell location for each error / warning.

[0086] In this embodiment, the rules are configurable and extensible to adapt to different project needs; the rules work in conjunction with AI to cover both precise and ambiguous scenarios; automatic version comparison and change history generation eliminate human error; error reports provide cell location for quick correction; and automatic repair of six common errors significantly improves efficiency and forms a closed-loop quality assurance system.

[0087] In this embodiment, automatic version comparison and change history generation are employed to avoid omissions and errors that may occur during manual comparison, ensuring that all differences between versions are captured completely and accurately. The automatically generated, uniformly formatted change history provides a reliable, complete, and traceable version history for the iterative development of the communication matrix, greatly improving the informatization level of version management. A classification-based automatic repair strategy based on repair templates is adopted to standardize and automate the repair of common errors, transforming the random repair process dependent on personal experience into a rule-driven, standardized automatic operation. This significantly improves repair efficiency and quality, prevents the recurrence of the same errors, and forms a closed-loop quality control process from detection to automatic repair to result recording.

[0088] In some embodiments, the method further includes: obtaining a set of incremental matrix candidate schemes based on atomic operation parsing; performing real-time verification and conflict arbitration based on the incremental matrix candidate scheme set to obtain a target incremental matrix; integrating the target incremental matrix with the original communication matrix to generate an initial vehicle communication matrix; and performing physical routing planning on the initial vehicle communication matrix based on a network topology model to generate an enhanced vehicle communication matrix.

[0089] Specifically, the process involves standardized input and atomic operation generation of a multi-source matrix. A first matrix, generated based on the System Functional Specification (SSTS), is obtained. Signals in this first matrix are extracted from the platform's signal library through a semantically driven requirement mapping mechanism, fully inheriting the predefined attribute sets in the signal library, including message definition attributes, signal definition attributes, signal location attributes, logical transmit / receive attributes, and signal delay attributes. A source requirement tag is attached to each signal to record its SSTS origin. Simultaneously, a second matrix (Electronic Control Unit (ECU) change set), submitted based on a structured template and already reviewed, is received from the collaborative feedback platform. This second matrix includes change requirements proposed by the ECU, with each change requirement including at least a change type attribute, signal definition attribute, signal semantic attribute, logical transmit / receive attribute, and signal delay attribute.

[0090] For example, the change type attribute of each record is parsed and converted into executable atomic operation instructions. For example, atomic operations include at least: ADD_SIGNAL (add signal), MODIFY_SIGNAL_ATTRIBUTE (modify signal attribute), and DELETE_SIGNAL (delete signal). Each instruction is associated with a globally unique identifier of the target signal and a complete set of change attributes.

[0091] Specifically, this step involves differentiated merging based on atomic operations and pre-design of the platform library (generating candidate schemes for the second matrix). Using the platform signal library as the design benchmark, this step calls the corresponding execution engine one by one for the atomic operation instruction stream corresponding to the second matrix (ECU change set) generated by the above multi-source matrix standardization input and atomic operation generation steps. Within the context of the platform library, intelligent matching of messages, pre-layout of physical bit fields, and attribute updates are completed, generating an "incremental matrix (candidate version)," i.e., a candidate implementation result, with complete implementation attributes. Each signal in this incremental matrix (candidate version) candidate scheme set obtains a message identifier (ID) based on the current state decision of the platform library and a pre-allocated physical bit field, serving as input to the rule engine for subsequent real-time verification and conflict arbitration steps.

[0092] Specifically, the rule engine performs real-time verification and conflict arbitration. This step receives the incremental matrix candidate solution set output from the differential merging based on atomic operations and the platform library pre-design step. The rule engine scheduling architecture performs real-time verification and conflict arbitration on each operation to ensure the final incremental matrix has integrity, consistency, and compliance within the platform library context. After successful verification and arbitration, the resulting "incremental matrix (fixed version)," i.e., the target incremental matrix, serves as input for subsequent incremental design integration and platform / vehicle model decision-making steps. The rule base includes various rules for resolving conflicts related to signal naming, message identifier (ID) allocation, and signal layout. The conflict arbitration mechanism includes at least: signal naming standardization verification rules, message identifier allocation rules, and signal layout optimization rules.

[0093] In one embodiment, the operation type identifier includes: adding a signal, modifying signal attributes, and deleting a signal. Dynamic loading and scheduling of rule chains: The rule chain scheduler dynamically loads predefined rule chains according to the operation type identifier and executes them sequentially. The predefined rule chains include: the add signal operation rule chain (ADD_SIGNAL operation rule chain), the modify signal attribute operation rule chain (MODIFY_SIGNAL_ATTRIBUTE operation rule chain), and the delete signal operation rule chain (DELETE_SIGNAL operation rule chain). Specifically, the ADD_SIGNAL operation rule chain includes: signal naming compliance rules → signal-message matching decision rules → physical layout conflict detection rules; the MODIFY_SIGNAL_ATTRIBUTE operation rule chain includes: impact analysis rules (determining whether the layout has changed) → physical layout conflict detection rules; and the DELETE_SIGNAL operation rule chain includes: deletion feasibility rules. For example, after each rule is executed, a status code and execution details are returned. The status codes include: SUCCESS, CONFLICT, and NEED_HUMAN. Among them, SUCCESS: Validation passed, subsequent rules can continue to be executed. CONFLICT: A fatal conflict was detected, the current candidate solution is not feasible, and it needs to be handled according to the policy. NEED_HUMAN: The rule itself requires manual confirmation, the process is paused and awaits intervention.

[0094] Specifically, rule execution and conflict detection. The following explains the specific implementation logic of each rule. For the newly added signal ADD_SIGNAL, the new signal operation rule chain is executed: signal naming compliance rule → signal-message matching decision rule → physical layout conflict detection rule.

[0095] For example, signal naming compliance rules include: verifying whether candidate names conform to platform specifications: length ≤ 32, containing only numbers / letters / underscores, starting with a letter, and conforming to English abbreviation standards, etc. The system checks the uniqueness of names in the platform's signal library and whether they are duplicates of other newly added signal names. If the name format is non-compliant, a status code NEED_HUMAN is returned with details of the format error; if there is a uniqueness conflict, a status code CONFLICT is returned with conflict details (e.g., suggestions for existing similar names); otherwise, a status code SUCCESS is returned, and the name is selected.

[0096] For example, the signal-message matching decision rules include: resource conflict rules, ID-period logic matching rules, and matching degree threshold rules. Specifically, the resource conflict rule checks whether the pre-assigned temporary ID is unique in the platform library and in this new addition if the candidate solution involves creating a new message. Since the rule engine has already selected from the available ID pool, it is usually unique, but it needs to be confirmed whether other parallel additions in concurrent scenarios occupy the same ID. If there is a conflict, the status code CONFLICT is returned and a backtracking is triggered, requiring the rule engine to reselect the ID; if the ID is unique, the process continues. The ID-period logic matching rule verifies whether the message ID conforms to the period-ID mapping relationship defined by the platform (e.g., a 10ms message ID must be in the range of 0x10~0xFF). If it does not conform, the status code CONFLICT is returned and the solution is eliminated. The matching degree threshold rule checks whether the candidate solution score is higher than a preset threshold (e.g., 80%). If the highest-scoring solution meets the criteria, the message is automatically selected, and the status code SUCCESS is returned. If multiple high-scoring solutions exist (all meet the criteria) or all solutions fail to meet the criteria, the meta-arbitrator is triggered, and the rule returns the status code SUCCESS with a multi-solution flag. It should be noted that if all candidate solutions are eliminated due to severe conflicts, the status code CONFLICT is returned.

[0097] For example, physical layout conflict detection rules include: bit field overlap rules, reserved bit / extended bit constraint rules, and load rate warning rules. The bit field overlap rule checks whether the layout scheme overlaps with the bit fields of other concurrently added signals (from the same batch, temporary states not yet merged into the platform library) within the same message. Since the rule engine generates layouts sequentially, multiple new signals may be assigned to the same bit field interval in the same message; this rule is used to capture such concurrent conflicts. If overlap is found, the status code CONFLICT is returned. The reserved bit / extended bit constraint rule confirms that the layout does not encroach on reserved areas or extended bits defined by the platform (e.g., diagnostic reserved bits, security extended bits). If encroachment is found, the status code CONFLICT is returned. The load rate warning rule triggers a warning if the message load rate exceeds a threshold (e.g., 85%) after layout, but can be allowed to continue according to project policy (returning the status code SUCCESS with an additional warning). If the layout scheme is marked as "layout unsolvable" (the rule engine cannot find a free bit field), the status code CONFLICT is returned directly.

[0098] Specifically, for modifying the signal attribute MODIFY_SIGNAL_ATTRIBUTE, the signal attribute modification operation rule chain includes: impact analysis rule (determining whether the layout has changed) → physical layout conflict detection rule. For example, the impact analysis rule receives the impact analysis results provided by the rule engine and determines whether the attribute change involves a layout change. If not, it directly returns SUCCESS; if so, it continues with the subsequent layout conflict detection rule. The physical layout conflict detection rule can refer to the rule chain described above.

[0099] Specifically, for the DELETE_SIGNAL signal, the signal deletion operation rule chain includes: deletion feasibility rules. For example, the deletion feasibility rules: verify whether the target signal exists in the current vehicle model project; check whether the target signal is referenced by other dependencies in the current vehicle model, including but not limited to cross-signal calculation functions, diagnostic events, network management-related configurations, etc.; if dependencies exist, return the status code CONFLICT with dependency details (e.g., dependency type, location); if no dependencies exist, return the status code SUCCESS, allowing the signal to be marked as "disabled" in the application context of the current vehicle model.

[0100] In one embodiment, a meta-arbitrator makes the decision. When multiple candidate solutions appear in the rule chain (e.g., multiple messages all meet the matching criteria) or when there are conflicting recommendations between rules, the meta-arbitrator makes the final decision based on a project-level strategy matrix. The strategy matrix includes, but is not limited to, the following decision factors and their weights: functional coupling, prioritizing the message that best matches the signal semantics (high weight); bus load balancing, prioritizing the message with a lower load rate to avoid overloading individual messages (medium weight); platform reuse potential, prioritizing designs that may be reused by other vehicle models (medium weight); historical design inertia, prioritizing the historical layout preference of signals from the same ECU or functional domain (low weight). The meta-arbitrator comprehensively scores each candidate solution, outputs the solution with the highest score, and records the decision reason (e.g., "functional coupling priority, select message 0x2A0"). If all solutions have the same score or are all below the threshold, manual intervention can be suspended.

[0101] Specifically, upon detecting a fatal conflict, the engine handles it according to predefined strategies, including backtracking and retrying: If the conflict is backtrackable (e.g., ID conflicts can be reselected, layout conflicts can try other candidate messages), the engine backtracks to the corresponding decision point, requests the rules engine to provide an alternative, and re-executes subsequent rules. Suspend manual intervention: If all branches fail or the conflict cannot be resolved automatically (e.g., no available IDs within the ID range, no solution for the layout), the current operation is suspended, the conflict context is recorded, and manual intervention is awaited. Force continuation: For non-fatal conflicts (e.g., load exceeding limits but acceptable), execution can continue after marking a warning according to project policies (returning the status code SUCCESS with an additional warning).

[0102] Specifically, all state transitions, decision paths, and conflict contexts are recorded in real time by the rule execution context, forming an execution trajectory log at the atomic operation level.

[0103] Specifically, the arbitration result is output. After rule chain verification and arbitration, an arbitrated design implementation increment matrix is ​​generated. The arbitrated design implementation increment matrix includes: the final implementation of each atomic operation (message ID, bit field position, signal attributes, etc.); the official ID and attributes of all newly created messages (if the new message passes arbitration); the updated attributes and layout of all modified signals; and the final status of each operation ("Designed", "Arbitrated", "Manually Confirmed"). A full-process execution trajectory log is also attached for subsequent integration and traceability by the rule engine.

[0104] Specifically, this involves designing incremental integration and platform / model decisions. This step integrates the arbitrated "incremental matrix (fixed version)," i.e., the target incremental matrix, into the first matrix (original communication matrix) of the current model, and completes platform / model synchronization decisions. Incremental integration design: The "incremental matrix (fixed version)" produced by the above rule engine real-time verification and conflict arbitration steps is merged into the first matrix extracted from the platform library, representing the current baseline of the model, generating the initial version of the vehicle communication matrix. Platform / model dual-layer synchronization decisions: A decision is made regarding whether to feed back the integrated change results to the platform mainline. Platform entry decision: The "incremental matrix (fixed version)" is submitted to the platform signal library to create a new version for reuse by other models; Model-specific decisions only take effect as a specific configuration for the current model, achieving isolation through model project tags.

[0105] Specifically, the optimal route is automatically generated and an enhanced matrix is ​​marked. The initial vehicle communication matrix, derived from the merging of the first and second matrices (an incremental matrix fixed version based on the platform signal library) from the incremental integration and platform / vehicle model decision steps, is automatically planned based on the vehicle network topology model of the specific vehicle model. The optimal physical route path is then automatically planned for signals transmitted across network segments, and gateway transmit / receive relationships are marked in the communication matrix, generating an "enhanced vehicle communication matrix." This step utilizes a topology-aware multi-objective optimization algorithm to achieve global load balancing between gateways and the bus while satisfying signal delay constraints.

[0106] For example, multi-source input modeling and data preparation are performed. Three types of input data are received and integrated: Input A (initial vehicle communication matrix), Input B (vehicle network topology model), and Input C (routing strategy and constraint library). Input A (initial vehicle communication matrix): This receives the initial version of the vehicle communication matrix (initial vehicle communication matrix) obtained by merging the first matrix and the second matrix (an incremental matrix fixed version based on the platform signal library). This initial vehicle communication matrix includes the logical transmit / receive attributes of each signal (logical sender ECU and logical receiver ECU); message attributes (message period, message length); and signal delay attributes (maximum delay time). Input B (network topology model): This obtains a structured vehicle network topology definition. The network topology model abstracts the vehicle network as a graph composed of nodes and edges; where nodes include ECUs, gateways, and their ports; edges represent physical links (e.g., CAN or CANFD bus) and have bandwidth and network segment attributes. Input C (routing policy and constraint library): predefined policies and hard constraints required for routing decisions, including the maximum allowable load rate threshold for each network segment, the routing and protocol conversion capabilities of each type of gateway, the link transmission delay model, and the priority of optimization objectives (e.g., load balancing priority, or worst-case minimum delay priority).

[0107] Specifically, topology-aware global path search and multi-objective optimization are employed. Based on the network topology model, the following operations are performed for each signal in the communication matrix that needs to be transmitted across network segments: feasible path enumeration, constraint filtering, and global optimization decision. Feasible path enumeration: In the topology graph, all possible paths from the sender to each receiver are searched. Each path includes the sequence of gateways traversed, inbound and outbound ports, cumulative hop count, and estimated transmission delay. Constraint filtering: Based on the maximum allowable delay constraint of the signal and the estimated delay of the path, paths that do not meet the timeliness requirements are filtered out. Global optimization decision: The path selection problem for all signals is constructed as a global multi-objective optimization problem. The decision variable is the specific path selected for each signal-receiver pair. The optimization objectives include at least: a) minimizing the maximum gateway load: avoiding a single gateway becoming a performance bottleneck; b) minimizing the worst-case end-to-end delay: ensuring the real-time performance of critical signals; c) minimizing the total number of routing hops: reducing overall network complexity and cumulative delay. An algorithm is used to solve this optimization problem, allocating appropriate physical routing paths to all signals. The solution algorithm can employ a multi-objective optimization solver based on genetic algorithms, such as a Pareto-optimal non-dominated sorting genetic algorithm (e.g., NSGA-II). This embodiment does not impose any restrictions on the specific algorithm. The input includes a list of feasible paths for all signal-receiver pairs, parameters of the hard constraints, and the priority of the optimization objectives (e.g., load balancing priority, while also considering latency).

[0108] Specifically, this involves routing information labeling, conflict resolution, and matrix enhancement. Result labeling: The final routing path result obtained from the optimization solution (the solution result) is automatically backfilled into the original communication matrix in the form of structured fields, generating an "enhanced vehicle communication matrix." For each transmitter and receiver of each signal, its routing path sequence, gateways along the way, routing type (direct connection / gateway forwarding), and calculated expected delay are independently labeled.

[0109] Specifically, it enables configuration and intelligent report generation. Gateway configuration is automatically generated: based on the enhanced vehicle communication matrix, a dedicated, directly deployable configuration file (e.g., ARXML, DBC extension file) is automatically generated for each gateway in the network. This configuration file explicitly defines: a routing table, specifying the input port, output port, and forwarding conditions for signals that need to be forwarded.

[0110] For example, a multi-dimensional network performance analysis report is automatically generated, which includes: load rate statistics and trend charts for each CAN / CAN FD network segment; CPU and memory load estimates for each gateway; end-to-end latency analysis of key signal flows to identify latency bottlenecks; and analysis of the impact of routing changes to provide quantitative basis for architecture optimization.

[0111] Specifically, this involves change synchronization and end-to-end traceability. All outputs generated from this routing plan (enhanced vehicle communication matrix, gateway configuration files, network performance analysis reports) are associated and stored with the input communication matrix baseline and topology model version. When the inputs (requirements, matrix, topology) change, incremental route replanning can be quickly initiated, clearly identifying the affected signals, gateway configurations, and network performance metrics, achieving end-to-end traceability of the impact of changes from physical routes back to logical requirements.

[0112] In some embodiments, the method further includes: obtaining a network segment and node configuration table and a gateway node configuration table; obtaining a custom configuration splitting rule and determining a splitting dimension based on the custom configuration splitting rule; performing multi-dimensional splitting on the target vehicle communication matrix based on the splitting dimension and the network segment and node configuration table and the gateway node configuration table to obtain a split sub-matrix file; and converting the split sub-matrix file into a target format file and distributing it.

[0113] Specifically, the system involves multi-dimensional segmentation and automatic distribution. The final vehicle communication matrix (target vehicle communication matrix) for each verified vehicle model is input into the segmentation system. It intelligently segments the matrix based on multiple dimensions, including network segments, nodes, and vehicle configuration, generating various file formats such as EXCEL format network segment communication matrix, DBC format network description file, and PDF format communication matrix report. This data is then automatically distributed to each ECU supplier via a collaborative feedback platform. The segmentation and distribution process is fully logged to ensure version consistency and traceability.

[0114] It should be noted that the technical solution of this embodiment will be described in detail below with specific examples, such as the intelligent verification, repair, and change history generation of the communication matrix of a certain vehicle model project from version V2.0 to V2.1. The communication matrix version V2.0 (historical baseline) of a certain vehicle model project has been completed, and now it is necessary to verify, repair, and generate a change history for the upcoming V2.1 version.

[0115] Specifically, rule configuration. Users set the following in the configuration interface: maximum node name length is 32 characters, maximum message name length is 30 characters, and maximum signal name length is 30 characters; message type whitelist: default "Normal, NM, Diag", add "Test". Enable all rules; warning level rules can be enabled or disabled according to project needs (all warning rules are enabled in this example); error level rules are mandatory and cannot be disabled (displayed in gray on the interface). Automatically update the constraints of relevant rules.

[0116] For example, such as Figure 3As shown, step one involves rule parsing. A rule base containing 156 rules is loaded, and each rule is parsed using an NLP model to generate structured metadata and construct a rule knowledge graph. Example rules: R023: Message IDs cannot be duplicated, error level; R001: Node name length ≤ 32, can only contain letters, numbers, and underscores, warning level; R078: Signal arrangement cannot conflict, error level; R134: Signal value descriptions must be complete, fuzzy rules, mapped to warning level; R201: Enumerated values ​​cannot exceed the signal length range, error level; R202: Invalid values ​​cannot be duplicated with enumerated values, warning level; R203: Gateway nodes must exist in the vehicle model information list, error level; R204: The logical relationship between message sending type and signal sending type is correct, error level; R205: Invalid signal values ​​should be set to the maximum bus value, warning level; R206: Initial signal value should be set to 0, warning level; R207: The maximum / minimum bus value should be consistent with the physical value, error level; R208: Routing path gateway transmit / receive tags must be complete, error level.

[0117] Specifically, such as Figure 3 As shown, step two involves matrix model construction. The V2.0 baseline matrix model is constructed, including 38 ECUs, 156 messages, and 823 signals. The current V2.1 matrix model is constructed, including 39 ECUs, 162 messages, and 851 signals.

[0118] For example, such as Figure 3 As shown, step three involves multi-stage rule validation and anomaly detection. Issues discovered during validation are listed in Table 1.

[0119] Table 1

[0120]

[0121] Specifically, such as Figure 3 As shown, step four involves fusing and synthesizing the error report. A comprehensive error report is generated, with each error including its location and description.

[0122] For example, such as Figure 3 As shown, step five is intelligent diagnosis. The root cause is traced through the rule dependency graph; for example, R023 is caused by a newly added message, and R078 is caused by a modification of the signal length.

[0123] Specifically, such as Figure 3As shown, step six involves problem classification and intelligent repair. AI automatic repair includes: R001: Automatically rename “Sig@New1” → “Sig_New1”; R202: Automatically change invalid values ​​to 0xFE; R205: Automatically change invalid values ​​to 0xFF; R206: Automatically change the initial value to 0; R207: Automatically recalculate the maximum bus value of 1000 based on a precision of 0.1 and an offset of 0; R208: Automatically supplement the OIB output port “OIB@BCANFD” ​​and the ZCU transceiver port based on the routing path (ESC→OIB→ZCU→DCU); R204: Automatically change the signal transmission type to Cycle; R023: Automatically reassign the ID to 0x2B0; R134: Automatically supplement the enumeration values ​​“0x2: reserved, 0x3: fault”. Manual confirmation includes: R078: Provide three layout schemes for the user to choose from; R201: Prompt to correct enumeration values ​​or signal length; R203: Prompt to supplement the gateway node.

[0124] For example, such as Figure 3 As shown, a second verification is performed after step seven. The verification is repeated, and all errors and warnings are eliminated.

[0125] Specifically, such as Figure 3 As shown, step eight involves version comparison and change history generation. Comparing V2.1 (after repair) with V2.0, a change history is generated, including added, modified, and deleted items, along with repair records: "[Automatic Repair] Message ID 0x2A0→0x2B0; Signal Name Sig@New1→Sig_New1; Invalid Value 0x00→0xFF; Initial Value 0x05→0x00; Bus Maximum Value 900→1000; OIB Output Port Supplement; ZCU Transceiver Port Supplement; Enumeration Value Supplement 0x2, 0x3; Signal Transmission Type OnChange→Cycle. Manual Confirmation: Signal VehSpd Start Bit 16→40; Enumeration Value 0x100 Corrected to 0xFF; Gateway ADAS Added to Vehicle Model Information."

[0126] For example, such as Figure 3 As shown, step nine involves generating an intelligent report. The final report is output, including rule statistics, error / warning distribution, final change history, repair records, and cell locations.

[0127] Understandably, this example performs exceptionally well. The entire process is automated, efficient, and accurate. Many common errors are automatically corrected by AI, with only a few complex issues requiring manual confirmation.

[0128] The communication matrix verification and repair method provided in this embodiment includes: acquiring a preset structured rule base; constructing a rule knowledge graph based on the preset structured rule base; performing multi-stage rule verification on the enhanced vehicle communication matrix based on the rule knowledge graph to obtain rule verification results; generating a comprehensive error report based on the rule verification results and anomaly detection results, and extracting automatic repair issues from the comprehensive error report; performing repair operations on the automatic repair issues according to the repair template to update the enhanced vehicle communication matrix to obtain the target vehicle communication matrix and generate a change history. This embodiment achieves flexible configuration and differentiated management of verification rules through a configurable rule base structure, allowing for rapid adjustment of rule parameters across different projects without modifying program code, significantly reducing the complexity of multi-project maintenance. The introduction of multi-stage rule verification and anomaly detection avoids subjective differences in manual review, improving the consistency and reliability of verification results. The adoption of a classification-based automatic repair strategy based on repair templates enables standardized and automated repair of common errors, significantly improving repair efficiency and quality. Automatic version comparison generates change history, avoiding omissions and errors that may occur during manual comparison. The automatically generated, uniformly formatted change history provides a reliable, complete, and traceable version history for the iterative development of the communication matrix, greatly improving the informatization level of version management.

[0129] Reference Figure 4 , Figure 4 This is a structural block diagram of an embodiment of the communication matrix verification and repair system of the present invention. Figure 4 As shown, the communication matrix verification and repair system includes:

[0130] The rule base acquisition module 10 is used to acquire a preset structured rule base and construct a rule knowledge graph based on the preset structured rule base;

[0131] Rule verification module 20 is used to perform multi-stage rule verification on the enhanced vehicle communication matrix based on the rule knowledge graph to obtain rule verification results;

[0132] The result fusion and reporting module 30 is used to generate a comprehensive error report based on the rule verification results and anomaly detection results, and to extract automatic repair issues from the comprehensive error report.

[0133] The automatic repair module 40 is used to perform repair operations on the automatic repair type of problems according to the repair template, so as to update the enhanced vehicle communication matrix to obtain the target vehicle communication matrix and generate a change history.

[0134] The communication matrix verification and repair system provided in this embodiment enables flexible configuration and differentiated management of verification rules through a configurable rule base structure. Rule parameters can be quickly adjusted across different projects without modifying program code, significantly reducing the complexity of maintaining multiple projects. Multi-stage rule verification and anomaly detection are introduced to avoid subjective differences in manual review, improving the consistency and reliability of verification results. A classification-based automatic repair strategy based on repair templates is adopted to standardize and automate the repair of common errors, greatly improving repair efficiency and quality. Automatic version comparison generates change history, avoiding omissions and errors that may occur during manual comparison. The automatically generated, uniformly formatted change history provides a reliable, complete, and traceable version history for the iterative development of the communication matrix, greatly improving the informatization level of version management.

[0135] In addition, for technical details not described in detail in this embodiment of the communication matrix verification and repair system, please refer to the communication matrix verification and repair method provided in any embodiment of the present invention, which will not be repeated here.

[0136] Based on the same inventive concept, embodiments of the present invention also provide an electronic device. Figure 5 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Figure 5 As shown, an embodiment of the present invention provides an electronic device including: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement any of the communication matrix verification and repair methods described in the above embodiments; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0137] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0138] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0139] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0140] This invention also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements the steps of any of the communication matrix verification and repair methods described in the above embodiments. The computer-readable storage medium can be volatile or non-volatile.

[0141] This invention also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described communication matrix verification and repair method.

[0142] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0143] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0144] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0145] The computer program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the invention.

[0146] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0147] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0148] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0149] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0150] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0151] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of the invention as set forth in the appended claims.

Claims

1. A method for verifying and repairing a communication matrix, characterized in that, include: Obtain a preset structured rule base, and construct a rule knowledge graph based on the preset structured rule base; Based on the rule knowledge graph, a multi-stage rule verification is performed on the enhanced vehicle communication matrix to obtain the rule verification results; A comprehensive error report is generated based on the rule verification results and anomaly detection results, and automatic repair issues are extracted from the comprehensive error report. The automatic repair operation is performed on the problem according to the repair template to update the enhanced vehicle communication matrix, obtain the target vehicle communication matrix, and generate a change history.

2. The method according to claim 1, characterized in that, The step of obtaining a preset structured rule base and constructing a rule knowledge graph based on the preset structured rule base includes: Obtain a preset structured rule base; wherein each rule in the preset structured rule base includes metadata for describing attributes, and the metadata includes severity level and remediation template; A rule knowledge graph is constructed using the rules in the preset structured rule base as entity nodes and the dependencies between rules in the preset structured rule base as edges.

3. The method according to claim 1, characterized in that, The multi-stage rule verification of the enhanced vehicle communication matrix based on the rule knowledge graph yields the rule verification results, including: Obtain the enhanced vehicle communication matrix to be verified as the current communication matrix model; Based on the rule knowledge graph, the current communication matrix model is sequentially subjected to independent rule verification, dependent rule verification, and global consistency verification to obtain rule verification results. The independent rule verification includes performing format checks and value range checks; the dependent rule verification includes executing rule chains with dependencies based on topology order; and the global consistency verification includes performing cross-table association rules and network segment load rate checks.

4. The method according to claim 3, characterized in that, The process involves generating a comprehensive error report based on the rule verification results and anomaly detection results, and extracting automatically repairable issues from the comprehensive error report, including: For the fuzzy rules in the preset structured rule base, anomaly detection is performed on the current communication matrix model based on a machine learning model to obtain anomaly detection results; By combining the rule verification results and anomaly detection results, a comprehensive error report is generated. Based on the rule knowledge graph, the root cause of the error information in the comprehensive error report is traced, and the problem is divided into automatic repair problems and non-automatic repair problems according to the severity level and repair template.

5. The method according to claim 1, characterized in that, The step of performing repair operations on the automatically repaired issues according to the repair template to update the enhanced vehicle communication matrix, obtain the target vehicle communication matrix, and generate a change history includes: The historical communication matrix is ​​used as the baseline communication matrix model, and the enhanced vehicle communication matrix to be verified is used as the current communication matrix model. The repair template is used to automatically perform repair operations on the automatic repair type of problems in order to update the current communication matrix model; After the current communication matrix model is repaired, the updated current communication matrix model is compared with the baseline communication matrix model to generate a change history.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Obtain the candidate scheme set of incremental matrix based on atomic operation analysis; Real-time verification and conflict arbitration are performed on the candidate scheme set of the incremental matrix to obtain the target incremental matrix; The target incremental matrix is ​​integrated with the original communication matrix to generate the initial vehicle communication matrix; Based on the network topology model, physical routing planning is performed on the initial vehicle communication matrix to generate an enhanced vehicle communication matrix.

7. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Obtain the network segment and node configuration table and the gateway node configuration table; Obtain the custom configuration splitting rules, and determine the splitting dimensions based on the custom configuration splitting rules; Based on the splitting dimensions and combined with the network segment and node configuration table and the gateway node configuration table, the target vehicle communication matrix is ​​split in multiple dimensions to obtain the split sub-matrix file; The split sub-matrix files are converted into target format files and then distributed.

8. A communication matrix verification and repair system, characterized in that, include: The rule base acquisition module is used to acquire a preset structured rule base and construct a rule knowledge graph based on the preset structured rule base; The rule verification module is used to perform multi-stage rule verification on the enhanced vehicle communication matrix based on the rule knowledge graph, and obtain the rule verification result; The results fusion and reporting module is used to generate a comprehensive error report based on the rule verification results and anomaly detection results, and to extract automatic repair issues from the comprehensive error report. The automatic repair module is used to perform repair operations on the automatic repair type of problems according to the repair template, so as to update the enhanced vehicle communication matrix to obtain the target vehicle communication matrix and generate a change history.

9. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1 to 7.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.

Images