Multi-source vehicle-mounted communication demand merging verification arbitration method, system, device and medium

Abstract

This invention provides a method, system, device, and medium for merging, verifying, and arbitrating multi-source vehicle communication requirements, belonging to the field of vehicle technology. The method includes: acquiring a candidate scheme set of incremental matrices based on atomic operation parsing; determining the operation type identifier of the candidate scheme set of the incremental matrix; dynamically loading a predefined rule chain according to the operation type identifier; performing real-time verification and conflict arbitration on the candidate scheme set of the incremental matrix based on the rule chain to obtain a target incremental matrix; and integrating the target incremental matrix with the original communication matrix to generate a merged communication matrix. This invention dynamically loads a predefined rule chain according to the operation type identifier of atomic operations through rule chain scheduling, executes each rule and returns a status code, and drives process control through status codes. This significantly improves the flexibility and scalability when facing different operation types, and can automatically and differentiate processing strategies according to the different nature and severity of conflicts, improving the automation level of conflict handling.

Description

Technical Field

[0001] This invention relates to the field of vehicle technology, and in particular to a method, system, device and medium for merging and verifying multi-source vehicle communication requirements. Background Technology

[0002] During the merging of multi-source vehicular communication matrices, a set of candidate design schemes for the incremental matrix is ​​generated, including message matching candidates for newly added signals, bit field layout candidates, and layout adjustment schemes for modified signals. These candidate schemes need to undergo rigorous verification and conflict arbitration to ensure that the final design has integrity, consistency, and compliance within the platform library context. In related technologies, rule checks typically adopt a hard-coded, sequential execution approach, which lacks flexibility and struggles to handle concurrent conflicts and multi-scheme decisions. Summary of the Invention

[0003] This invention aims to solve at least one of the technical problems existing in the prior art, and proposes a method, system, device and medium for merging and verifying multi-source vehicle communication requirements.

[0004] In a first aspect, embodiments of the present invention provide a method for merging, verifying, and arbitrating multi-source vehicle communication requirements, including:

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

[0006] Determine the operation type identifier of the incremental matrix candidate scheme set, and dynamically load the predefined rule chain according to the operation type identifier;

[0007] Based on the rule chain, the candidate scheme set of the incremental matrix is ​​verified and conflict arbitration is performed in real time to obtain the target incremental matrix;

[0008] The target incremental matrix is ​​integrated with the original communication matrix to generate a merged communication matrix.

[0009] In some embodiments, the step of performing real-time verification and conflict arbitration on the incremental matrix candidate scheme set based on the rule chain to obtain the target incremental matrix includes:

[0010] The rules are executed on the incremental matrix candidate scheme set based on the rule chain, and a status code and execution details are returned after each rule is executed.

[0011] Based on the status code, rule chain verification and arbitration are performed to generate an arbitration-based design implementation increment matrix.

[0012] The target incremental matrix is ​​obtained by implementing the incremental matrix based on the arbitration-adjusted design.

[0013] In some embodiments, the step of performing rule chain verification and arbitration based on the status code includes:

[0014] If the status code is successful, execute the next rule;

[0015] When the status code is conflicting, a predefined strategy is triggered; wherein, the predefined strategy includes backtracking and retrying, suspending manual intervention, and forcing continuation;

[0016] When the status code indicates that manual intervention is required, the process is paused and a notification is triggered.

[0017] In some embodiments, the operation type identifier includes: adding a signal, modifying signal attributes, and deleting a signal; the predefined rule chain includes: adding a signal operation rule chain, modifying signal attributes operation rule chain, and deleting a signal operation rule chain.

[0018] In some embodiments, the step of executing rules on the incremental matrix candidate solution set based on the rule chain, and returning a status code and execution details after each rule is executed, includes:

[0019] When the operation type is identified as a new signal, the rules are executed on the incremental matrix candidate scheme set according to the order of the new signal operation rule chain, and a status code and execution details are returned after each rule is executed; wherein, the new signal operation rule chain includes: signal naming compliance rules, signal-message matching decision rules, and physical layout conflict detection rules.

[0020] In some embodiments, the step of executing rules on the incremental matrix candidate solution set based on the rule chain, and returning a status code and execution details after each rule is executed, includes:

[0021] When the operation type is identified as modifying signal attributes, the rules are executed on the incremental matrix candidate scheme set according to the order of the operation rule chain for modifying signal attributes, and a status code and execution details are returned after each rule is executed; wherein, the operation rule chain for modifying signal attributes includes: impact analysis rules and physical layout conflict detection rules.

[0022] In some embodiments, the step of executing rules on the incremental matrix candidate solution set based on the rule chain, and returning a status code and execution details after each rule is executed, includes:

[0023] When the operation type is identified as a deletion signal, rules are executed on the incremental matrix candidate scheme set based on the deletion signal operation rule chain, and a status code and execution details are returned after each rule is executed; wherein, the deletion signal operation rule chain includes: deletion feasibility rules.

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

[0025] When multiple candidate solutions or conflicting suggestions arise during rule chain execution, a comprehensive score is obtained based on a project-level strategy matrix. The project-level strategy matrix includes: functional coupling, bus load balancing, platform reuse potential, and historical design inertia.

[0026] The solution with the highest score is output as the arbitration result based on the scoring results, so as to generate the post-arbitration design implementation increment matrix.

[0027] In some embodiments, obtaining the candidate scheme set of incremental matrix based on atomic operation analysis includes:

[0028] Obtain change request information and abstract the change request information into atomic operation instructions; wherein, the atomic operation instructions include add signal instructions, modify signal attribute instructions, and delete signal instructions;

[0029] Based on the platform signal library, platform context-aware differential processing is performed on each atomic operation instruction to generate candidate implementation results of the atomic operation;

[0030] An incremental matrix candidate scheme set is generated based on the candidate implementation results.

[0031] Secondly, embodiments of the present invention provide a multi-source vehicle communication requirement merging verification arbitration system, comprising:

[0032] The candidate solution acquisition module is used to acquire a set of incremental matrix candidate solutions based on atomic operation parsing;

[0033] The rule dynamic loading module is used to determine the operation type identifier of the incremental matrix candidate scheme set and dynamically load the predefined rule chain according to the operation type identifier.

[0034] The verification and conflict arbitration module is used to perform real-time verification and conflict arbitration on the candidate scheme set of the incremental matrix based on the rule chain to obtain the target incremental matrix.

[0035] The communication matrix merging module is used to integrate the target incremental matrix with the original communication matrix to generate a merged communication matrix.

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

[0037] One or more processors;

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

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

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

[0041] The present invention provides a method for merging, verifying, and arbitrating multi-source vehicle communication requirements, comprising: acquiring a candidate scheme set of incremental matrices based on atomic operation parsing; determining the operation type identifier of the candidate scheme set of incremental matrices; dynamically loading a predefined rule chain according to the operation type identifier; performing real-time verification and conflict arbitration on the candidate scheme set of incremental matrices based on the rule chain to obtain a target incremental matrix; and integrating the target incremental matrix with the original communication matrix to generate a merged communication matrix. The present invention dynamically loads a predefined rule chain according to the operation type identifier of atomic operations through rule chain scheduling, executes each rule and returns a status code, and drives process control through status codes, significantly improving flexibility and scalability when facing different operation types. It can automatically and differentiatedly execute processing strategies according to the different nature and severity of conflicts, improving the automation level of conflict handling. Attached Figure Description

[0042] Figure 1 A flowchart illustrating a multi-source vehicle communication requirement merging verification and arbitration method provided in an embodiment of the present invention;

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

[0044] Figure 3 This is a schematic diagram of the execution flow of the newly added signal operation rule chain involved in this embodiment of the invention;

[0045] Figure 4 A structural block diagram of a multi-source vehicle communication requirement merging verification and arbitration system provided in an embodiment of the present invention;

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

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

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

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

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

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

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

[0053] In related technologies, candidate design schemes for generating incremental matrices based on atomic operations include message matching candidates for new signals, bit field layout candidates, and layout adjustment schemes for modified signals. These candidate schemes need to undergo rigorous verification and conflict arbitration to ensure that the final design has integrity, consistency, and compliance within the platform library context.

[0054] Rule checks typically employ a hard-coded, sequential execution approach, lacking flexibility and struggling to handle concurrent conflicts and multi-option decisions. Specific problems include: rigid rule organization, making it difficult to dynamically adjust validation logic based on operation type; a lack of unified process control mechanisms after conflict detection, hindering intelligent backtracking, retries, or suspension; a lack of decision-making basis when multiple candidate solutions exist, often relying on manual selection; and a lack of logging during rule execution, making problem traceability difficult.

[0055] Therefore, there is an urgent need for a dynamic scheduling and conflict arbitration method for rule engines, which can dynamically load rule chains according to operation type, drive process control through status codes, make intelligent decisions by the meta-arbitrator when there are multiple options, and record full process logs to support subsequent traceability.

[0056] To address at least one of the technical problems existing in the aforementioned related technologies, the present invention provides a multi-source vehicle communication requirement merging verification arbitration method. Figure 1 This is a flowchart illustrating a multi-source vehicle communication requirement merging verification and arbitration method provided in an embodiment of the present invention.

[0057] As one embodiment of the present invention, such as Figure 1 As shown, the multi-source vehicle communication requirement merging verification arbitration method includes:

[0058] Step S1: Obtain the candidate scheme set of incremental matrix based on atomic operation analysis;

[0059] Step S2: Determine the operation type identifier of the incremental matrix candidate scheme set, and dynamically load the predefined rule chain according to the operation type identifier;

[0060] Step S3: Based on the rule chain, perform real-time verification and conflict arbitration on the candidate scheme set of the incremental matrix to obtain the target incremental matrix;

[0061] Step S4: Integrate the target incremental matrix with the original communication matrix to generate a merged communication matrix.

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

[0063] Specifically, this embodiment is applicable to vehicle network communication design, and uses a rule engine for dynamic scheduling and conflict arbitration of CAN / CAN FD communication matrix generation to perform real-time verification and intelligent arbitration of candidate design schemes generated during the multi-source merging process.

[0064] For example, in this embodiment, the method dynamically loads a predefined rule chain based on the atomic operation type through a rule chain scheduler, executes each rule sequentially, and returns a status code (SUCCESS / CONFLICT / NEED_HUMAN). The state machine controls the flow based on the status code: SUCCESS continues to the next rule; CONFLICT triggers a backtracking retry, suspends manual intervention, or forces continuation; NEED_HUMAN pauses the process and waits for manual intervention. When multiple candidate solutions or conflicting suggestions between rules occur, the meta-arbitrator makes the final decision based on the project strategy matrix. After all rules have been executed, the arbitrated design result is output, along with a full-process execution trajectory log. The following describes the specific steps.

[0065] In some embodiments, obtaining a candidate scheme set for an incremental matrix based on atomic operation parsing includes: obtaining change requirement information and abstracting the change requirement information into atomic operation instructions; wherein, the atomic operation instructions include adding signal instructions, modifying signal attribute instructions, and deleting signal instructions; performing platform context-aware differential processing on each atomic operation instruction based on the platform signal library to generate candidate implementation results of the atomic operation; and generating a candidate scheme set for an incremental matrix based on the candidate implementation results.

[0066] Specifically, such as Figure 2 As shown, the system receives a set of candidate schemes from the atomic operation parsing engine. Each candidate scheme includes: an operation type identifier, naming candidates, message matching candidates, layout candidates, and other context data. The operation type identifier includes, for example, ADD_SIGNAL (add signal), MODIFY_SIGNAL_ATTRIBUTE (modify signal attributes), or DELETE_SIGNAL (delete signal); naming candidates include, for example, for the ADD operation, the corrected candidate names; message matching candidates include, for example, for the ADD operation, a list of candidate messages (each message has attributes such as ID, period, load rate, and remaining space) and a matching score; layout candidates include, for example, for the ADD and MODIFY operations, layout schemes (start bit, length, message load rate, etc.); and other context data includes, for example, signal definition attributes and logical transmit / receive attributes.

[0067] For example, signal change sets from multiple Electronic Control Units (ECUs) are received. These sets are submitted based on structured templates, and each change request includes at least change type attributes, signal definition attributes, signal semantic attributes, logical transmit / receive attributes, and signal delay attributes. Each change request in the signal change set is parsed and converted into a corresponding atomic operation instruction (ADD, MODIFY, DELETE) based on the change type attribute. Each instruction is associated with a globally unique identifier for the target signal and a complete set of change attributes. Based on the platform's signal library, each atomic operation is processed differently directly within the platform library. During processing, each key decision point (e.g., candidate message selection, layout scheme selection, attribute change feasibility, etc.) is submitted to an external rule engine for verification. The verification result determines whether to continue the current path or whether adjustments are needed.

[0068] Specifically, for the ADD_SIGNAL operation, the processing flow of the atomic operation instruction (ADD_SIGNAL) includes: performing a platform library existence check, and searching for a matching existing signal in the platform signal library based on the signal semantics, globally unique identifier, or attribute combination provided by the ECU. Each signal in the platform signal library has a globally unique name and coded identifier to ensure accurate matching.

[0069] For example, for the ADD_SIGNAL operation, in case one, the signal already exists in the platform signal library. If a matching signal exists, it is directly confirmed that the signal is defined in the platform library, and no creation operation is required. The complete standard attributes of the signal (including message definition attributes, signal definition attributes, signal location attributes, logical transmit / receive attributes, and signal delay attributes) exist in the platform library and can be directly referenced by all vehicle model projects.

[0070] For example, for the ADD_SIGNAL operation, case two: the signal does not exist in the platform signal library. If no matching signal exists, it is treated as a completely new signal, requiring a creation operation in the platform signal library: a) signal naming correction; b) intelligent matching within the platform library; c) automatic spatial optimization layout; d) supplementing logical transmit / receive attributes and signal delay attributes. Through the above creation operation, the new signal is completely created in the platform signal library, and all its attributes are defined at the platform level, allowing direct reference by all current and future vehicle model projects.

[0071] For example, signal naming correction: The signal naming standardization correction module is called to verify and correct the original signal name according to the platform's predefined naming rules (e.g., length ≤ 32, only numbers / letters / underscores, first character must be a letter, English abbreviation standard, etc.), generate a standardized signal name that conforms to the standard, and write the name into the library as the globally unique identifier of the signal in the platform library.

[0072] For example, the platform library performs intelligent matching by invoking the signal-message intelligent matching subsystem to calculate the matching degree of candidate messages based on the following multi-dimensional features: signal semantic similarity: the degree of semantic matching between the signal semantic attributes provided by the ECU and the message functional classification; period matching degree: the degree of matching between the expected transmission period of the signal and the message period; data length compatibility: whether the remaining space of the message meets the signal length requirements; historical correlation: the historical layout preference of signals from the same ECU or the same functional domain. Messages that may carry the signal (including existing messages and new message options) are selected from the platform signal library, and a matching degree score is calculated, outputting the N candidate schemes with the highest scores. For new message options, a formal CAN ID is assigned according to the period-ID mapping rule: the ID range to which the signal belongs is determined based on the signal's transmission period (e.g., a 10ms message corresponds to an ID range of 0x10~0xFF, a 20ms message corresponds to 0x100~0x1FF, etc.), and an ID is selected from the currently available ID pool within that range as the formal ID. A dynamically updated ID usage status table is maintained. Each time an ID is assigned to a new message, it is marked as occupied in the ID pool for the corresponding period range, ensuring that subsequent new messages do not select the same ID repeatedly. The initial state of the ID pool is generated based on existing message IDs in the platform's signal library. The complete definition of a new message (including message ID, period, length, etc.) is also written into the platform's signal library. Candidate schemes are submitted to an external rule engine for verification, and the final selected message is determined based on the verification results.

[0073] For example, automatic spatial optimization layout: For the finally selected message (whether an existing message or a newly created message), based on the current bit field occupancy map of the message (which records the start bit, length, and reserved area of ​​the allocated signals), an idle bit field query is performed. From the continuous idle bit field intervals that can accommodate the signal length, the start bit is selected according to a preset optimization strategy (e.g., best fit, first fit, load balancing priority), and a layout scheme is generated. This layout scheme is submitted to an external rule engine for verification. After the verification is passed, the signal position attributes (start byte, arrangement format) are written into the platform signal library.

[0074] For example, supplement the logical transmit / receive attributes and signal delay attributes: extract the logical transmit / receive attributes (logical sender ECU and logical receiver ECU) and signal delay attributes (maximum delay time) from the ECU change set, and write these attributes as the default attributes of the signal into the platform signal library.

[0075] Specifically, for the MODIFY_SIGNAL_ATTRIBUTE operation: the atomic operation instruction is the signal attribute modification instruction (MODIFY_SIGNAL_ATTRIBUTE). The processing flow includes: change impact analysis; layout recalculation; and attribute update. Change impact analysis: Locate the target signal in the platform's signal library and analyze whether attribute changes (e.g., signal length, precision, offset, range, etc.) affect the current physical layout. For example, special attention needs to be paid to changes in signal length, as length changes may directly lead to insufficient bit fields in the original layout. Layout recalculation: If the change affects the layout (e.g., increased length leading to insufficient space in the original position), the layout recalculation algorithm is invoked. While maintaining the original message ID, free bit fields are queried based on the current message's bit field occupancy map. Attempts are made to rearrange the signal bit fields, prioritizing finding new free areas within the current message to accommodate the signal, while minimizing the movement of other signals within the same message. If the signal cannot be accommodated, multiple layout adjustment schemes are generated, including but not limited to: moving within the current message, extending the message length, and migrating to other messages. Multiple candidate schemes are submitted to an external rule engine for verification, and the final scheme is selected based on the verification results. Attribute Update: Based on the rule engine's validation results, the signal position attributes (starting byte) and signal definition attributes (such as precision and range) are synchronously updated in the platform signal library. The modified signal will be used as the new version of the platform library for subsequent vehicle model projects.

[0076] Specifically, for the DELETE_SIGNAL operation, the atomic operation instruction for deleting a signal (DELETE_SIGNAL) includes the following processing steps: deactivation marking or removal. Based on the platform management policy, one of the following operations is performed: If the signal may continue to be used by some vehicle models, the signal is marked as "deactivated" in the platform signal library for the current vehicle model context, releasing the message bit field resources it occupies in the current vehicle model, but retaining the signal definition for reuse by other vehicle models; if the signal is no longer used in all vehicle models, the signal and its related attributes are completely removed from the platform signal library, and the ID and bit field resources are reclaimed. The feasibility of the deletion operation (e.g., whether there are dependent references) can be verified through an external rule engine.

[0077] In this embodiment, the change requirements are abstracted into atomic operations and incrementally differentiated based on the platform signal library. This avoids the loss of original design data caused by the overall coverage method and preserves the layout results already completed in the first communication matrix. At the same time, by combining atomic operations with incremental matrix merging, the structured and automated integration of multi-source requirements is realized, which significantly improves the generation efficiency of the communication matrix and reduces the risk of data inconsistency caused by human error.

[0078] In some embodiments, an operation type identifier is determined for the incremental matrix candidate scheme set, and a predefined rule chain is dynamically loaded based on the operation type identifier.

[0079] In some embodiments, real-time verification and conflict arbitration are performed on the incremental matrix candidate scheme set based on the rule chain to obtain the target incremental matrix, including: executing rules on the incremental matrix candidate scheme set based on the rule chain, and returning a status code and execution details after each rule is executed; performing rule chain verification and arbitration based on the status code to generate an arbitration-adjusted design implementation incremental matrix; and obtaining the target incremental matrix based on the arbitration-adjusted design implementation incremental matrix.

[0080] In some embodiments, the operation type identifier includes: adding a signal, modifying signal attributes, and deleting a signal; the predefined rule chain includes: adding a signal operation rule chain, modifying signal attributes operation rule chain, and deleting a signal operation rule chain.

[0081] Specifically, such as Figure 2 As shown, the rule chain is dynamically loaded and scheduled: the rule chain scheduler dynamically loads predefined rule chains based on the operation type identifier and executes them sequentially. 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).

[0082] For example, 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.

[0083] In some embodiments, executing rules on the incremental matrix candidate scheme set based on the rule chain and returning a status code and execution details after each rule is executed includes: when the operation type is identified as a new signal, executing rules on the incremental matrix candidate scheme set based on the order of the new signal operation rule chain, and returning a status code and execution details after each rule is executed; wherein, the new signal operation rule chain includes: signal naming compliance rules, signal-message matching decision rules, and physical layout conflict detection rules.

[0084] Specifically, such as Figure 2 As shown, rule execution and conflict detection are performed. The specific implementation logic of each rule is explained below. For the newly added signal ADD_SIGNAL, as follows... Figure 3As shown, the new signal operation rule chain is executed as follows: signal naming compliance rule → signal-message matching decision rule → physical layout conflict detection rule.

[0085] 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 (such as suggestions for existing similar names); otherwise, a status code SUCCESS is returned, and the name is selected.

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

[0087] 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 (such as 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.

[0088] In some embodiments, executing rules on the incremental matrix candidate scheme set based on the rule chain and returning a status code and execution details after each rule is executed includes: when the operation type is identified as modifying signal attributes, executing rules on the incremental matrix candidate scheme set based on the order of the modify signal attribute operation rule chain, and returning a status code and execution details after each rule is executed; wherein, the modify signal attribute operation rule chain includes: impact analysis rules and physical layout conflict detection rules.

[0089] Specifically, for modifying the signal attribute MODIFY_SIGNAL_ATTRIBUTE, the signal attribute operation rule chain is modified, including: impact analysis rule (determining whether the layout has changed) → physical layout conflict detection rule.

[0090] For example, the impact analysis rule receives the impact analysis results provided by the rule engine and determines whether the attribute change involves layout changes. If not, it directly returns SUCCESS; if so, it continues with subsequent layout conflict detection rules.

[0091] 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 (such as 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.

[0092] In some embodiments, executing rules on the incremental matrix candidate solution set based on the rule chain and returning a status code and execution details after each rule is executed includes: when the operation type is identified as a deletion signal, executing rules on the incremental matrix candidate solution set based on the deletion signal operation rule chain and returning a status code and execution details after each rule is executed; wherein, the deletion signal operation rule chain includes: deletion feasibility rules.

[0093] Specifically, for the DELETE_SIGNAL signal, the deletion signal operation rule chain includes: deletion feasibility rules.

[0094] For example, the deletion feasibility rule is as follows: 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.

[0095] In this embodiment, rule chain scheduling is introduced. Based on the received atomic operation type identifier (e.g., ADD_SIGNAL, MODIFY_SIGNAL_ATTRIBUTE, DELETE_SIGNAL), a rule chain uniquely corresponding to that operation type is dynamically loaded from a predefined rule base and executed sequentially. Each rule chain consists of multiple independent rules (e.g., naming compliance rules, message matching decision rules, physical layout conflict detection rules, etc.). The technique of dynamically loading rule chains using rule chain scheduling decouples the rule logic from the execution scheduling logic. When a new operation type needs to be added or the verification logic of a certain type of operation needs to be adjusted, only the rule chain definition or the rule itself in the rule base needs to be modified, without changing the core scheduling code, significantly improving flexibility and scalability when dealing with different operation types.

[0096] In some embodiments, the method further includes: when multiple candidate solutions or conflicting recommendations between rules occur during rule chain execution, a comprehensive score is performed based on a project-level strategy matrix to obtain a score result; wherein the project-level strategy matrix includes: functional coupling degree, bus load balancing, platform reuse potential, and historical design inertia; the solution with the highest score is output as the arbitration result based on the score result to generate an arbitration-based design implementation increment matrix.

[0097] Specifically, such as Figure 2 As shown, the meta-arbitrator makes decisions. When multiple candidate solutions appear in the rule chain (e.g., multiple messages meet the matching criteria) or when there are conflicting suggestions between rules, the meta-arbitrator makes the final decision based on the project-level strategy matrix. The strategy matrix includes, but is not limited to, the following decision factors and their weights: functional coupling degree, 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 models (medium weight); historical design inertia, prioritizing the historical layout preferences of signals from the same ECU or functional domain (low weight).

[0098] For example, the meta-arbitrator performs a comprehensive score on each candidate solution, outputs the solution with the highest score, and records the decision reason (e.g., "Functional coupling takes precedence, select message 0x2A0"). If all solutions have the same score or are all below the threshold, manual intervention can be suspended.

[0099] In this embodiment, a meta-arbitrator is introduced. The meta-arbitrator is configured to be triggered when multiple candidate solutions that pass verification are detected during the execution of the rule chain, or when conflicting suggestions are given by different rules. Based on a predefined project-level strategy matrix, multiple candidate solutions are comprehensively scored. This strategy matrix includes multi-dimensional decision factors and their weights (e.g., functional coupling, bus load balancing, platform reuse potential) and corresponding priorities. The meta-arbitrator ultimately selects the solution with the highest score as the arbitration result and records the reasoning for the decision. This embodiment introduces a meta-arbitrator and a project-level strategy matrix to achieve automatic and quantitative decision-making in situations with multiple candidate solutions. It transforms human experience into repeatable scoring rules, reducing the need for manual intervention, improving processing efficiency, and ensuring the consistency and reliability of decisions through a unified standard.

[0100] In some embodiments, rule chain verification and arbitration based on the status code includes: executing the next rule when the status code is successful; triggering a predefined strategy when the status code is conflicting; wherein the predefined strategy includes backtracking and retrying, suspending manual intervention, and forcing continuation; and pausing the process and triggering a notification when the status code indicates that manual intervention is required.

[0101] Specifically, each rule returns a status code and execution details after execution. Status codes include: SUCCESS, CONFLICT, and NEED_HUMAN. SUCCESS: Verification passed, subsequent rules can continue to be executed. CONFLICT: A fatal conflict was detected; the current candidate solution is not feasible and needs to be handled according to the strategy. NEED_HUMAN: The rule itself requires manual confirmation; the process is paused pending intervention.

[0102] For example, such as Figure 2 As shown, the state machine and process control: Based on the status codes returned by the rules, the engine controls the flow of the process. Status code SUCCESS: Continue executing the next rule; if all rules have been executed, proceed to the final output. Status code CONFLICT: A fatal conflict was detected; the engine handles it according to a predefined strategy. Status code NEED_HUMAN: The rule itself requires manual confirmation (e.g., non-compliant name format, first-time creation of a critical signal); the process is paused and a notification is triggered; it resumes after manual processing.

[0103] 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).

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

[0105] Specifically, such as Figure 2 As shown, 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.

[0106] In this embodiment, a state machine flow control mechanism is introduced, using the status code (e.g., SUCCESS, CONFLICT, NEED_HUMAN) returned after each rule execution as the core input for flow control. This state machine is configured to execute different branch logics based on the returned status code. For example, when CONFLICT is returned, the state machine can, according to a predefined strategy, choose to execute a backtracking retry (returning to the previous decision point to reselect), suspend the operation and record the conflict context for manual intervention, or mark a warning and force execution to continue. Because a status code-based flow control mechanism is constructed, processing strategies can be automatically and differentiated according to the different nature and severity of the conflict, effectively avoiding process interruptions or invalid attempts caused by a single processing logic (e.g., direct error reporting), thereby improving the automation level of conflict handling and system robustness.

[0107] This embodiment introduces a full-process execution trajectory logging mechanism. This mechanism is configured to record in real-time the state transitions of all rules, the path of each process decision, the specific context information of conflicts, and the final decision of the meta-arbitrator within a rule execution context. After execution, this log can be used as an auxiliary output of the arbitrated design implementation increment matrix for subsequent integration verification and issue tracing. This full-process execution trajectory logging mechanism provides a complete and traceable execution black box from candidate solution input to final arbitration result output. It enables precise backtracking of each rule execution and state transition step when problems occur, greatly improving the diagnosability and maintainability of complex decision-making processes.

[0108] It should be noted that the technical solution of the method in this embodiment will be described in detail below with reference to several specific embodiments.

[0109] Example 1: ADD_SIGNAL Operation (Adding a new signal, involving multi-scheme decision-making). In a vehicle model project development, ECU1 submits a change request for the ADD_SIGNAL operation: adding a pre-activation signal for automatic emergency braking with a transmission period of 10ms. The change set provided by the ECU includes the following signal semantic attributes: "Automatic emergency braking function pre-activation state, used to wake up the brake actuator"; signal definition attributes: length 2 bytes, type unsigned integer, precision 1, offset 0, initial value 0, invalid value 0xFFFF, range 0-100; logical transmit / receive attributes: the logical sender ECU is ADAS (Advanced Driver Assistance System), and the logical receiver ECU is EPS (Electronic Stability Program) or IC (Instrument Panel); signal delay attributes: maximum delay time 10ms. No matching signal was found in the platform signal library (no identical semantics or identifier), therefore, the signal needs to be created in the platform library, and the key decision is submitted to the rule engine for verification.

[0110] Specifically, step 1 is the atomic operation conversion. Generate the atomic operation instruction: ADD_SIGNAL(to be created, {semantic: "Automatic Emergency Braking Pre-Activation State...", length: 2 bytes, period: 10ms, sender: ADAS, receiver: EPS / IC, delay: 10ms}).

[0111] For example, step 2 performs a creation operation in the platform signal library. Signal naming correction: Based on the platform naming rules, the temporary name that may be provided in the original request (e.g., AEB_PreAct) is corrected to the standardized name ADAS_AEBPreActivSt, ensuring that this name is unique in the platform library. Intelligent matching within the platform library: Based on semantic similarity, periodic matching, etc., two candidate messages are selected from the platform signal library: Candidate message 1: Existing message 0x2A0 (functional label "ADAS status", period 10ms, load rate 75%, remaining space 4 bytes), matching score 95; Candidate message 2: Existing message 0x2C1 (functional label "general status", period 10ms, load rate 40%, remaining space 8 bytes), matching score 80. The candidate solutions are submitted to an external rule engine for real-time verification and conflict arbitration. The rule engine decides to select message 0x2A0 based on the project strategy (e.g., functional coupling priority). Simultaneously, the ID uses a status table to record all used IDs in the platform library. Automatic Space Optimization Layout: For message 0x2A0, its bit field occupancy map is queried. It is found that there are 16 free bits at start bit 32, which is selected as the layout scheme (start bit 32, length 16 bits, Intel format). The signal position attribute (start byte 4, i.e., start bit 32) is written to the platform library. Complete Attribute Writing: The signal definition attributes (length 2 bytes, precision 1, etc.), logical transmit / receive attributes (sender ADAS, receiver EPS, IC), and delay attribute (10ms) are all written to the platform signal library, completing the creation of the new signal.

[0112] Specifically, ADAS submits a new signal "ADAS_AEBPreActivSt", and the rule engine generates two candidate schemes. Scheme 1: Message 0x2A0, start bit 32, length 16 bits, matching score 95, message load rate after layout 81.25%; Scheme 2: Message 0x2C1, start bit 48, length 16 bits, matching score 80, message load rate after layout 43.75%. The rule engine receives the candidate scheme set, with the operation type being ADD_SIGNAL, and loads the corresponding rule chain.

[0113] For example, Rule 1, signal naming compliance rule: Verify the candidate name "ADAS_AEBPreActivSt": length 20, conforming to ≤32; all characters are letters / underscores; first character is a letter; conforms to platform abbreviation specifications. The name is unique when queried in the platform database. Return SUCCESS and select the name.

[0114] Specifically, Rule 2 is the signal-message matching decision rule. Resource conflict rule: Both schemes use existing messages, no need to verify the newly created ID, skip this step. ID-period logic matching rule: 0x2A0 and 0x2C1 both fall within the allowed range for 10ms messages (0x10~0xFF), return SUCCESS. Matching degree threshold rule: Both schemes score above the threshold of 80%, triggering the meta-arbitrator decision. Meta-arbitrator intervention: Based on the project strategy matrix, functional coupling has the highest weight. Scheme 1 message 0x2A0 has the functional label "ADAS status," which highly matches the signal semantics; Scheme 2 message 0x2C1 is "general status," with a lower matching degree. The meta-arbitrator decides to select Scheme 1, recording the reason "functional coupling takes precedence."

[0115] For example, rule 3 is the physical layout conflict detection rule. Check the layout of scheme 1 (message 0x2A0, start bit 32, length 16): no overlap with other newly added signals in the same batch; no encroachment on reserved bits (query the platform's reserved bit table, start bit 32 is not in the reserved area); load rate 81.25% < 85%, no warnings. Return SUCCESS.

[0116] Specifically, after all rules are executed, the arbitration result is output: Scheme 1 is selected, which is ultimately implemented as the signal "ADAS_AEBPreActivSt" belonging message 0x2A0, with a start bit of 32. The arbitration result is output to obtain the target increment matrix.

[0117] For example, in step 3, matrix merging and output, based on the incremental matrix (target incremental matrix) of the updated platform signal library, the target incremental matrix is ​​integrated with the first communication matrix (original communication matrix) to generate the merged communication matrix for the current vehicle model. The merged communication matrix includes the newly created signal "ADAS_AEBPreActivSt" and its complete attribute set, and carries the source requirement label "ADAS".

[0118] Example 2: MODIFY_SIGNAL_ATTRIBUTE Operation (Modify Signal, Multi-Layout Scheme Decision). The MODIFY_SIGNAL_ATTRIBUTE operation (modify signal attributes, update platform library). The existing signal "Wheel Speed ​​Signal" (Signal_B) is defined in the platform library as: 8 bits long, 0.1 km / h precision, located at start bit 16 of message 0x1C0 (Intel format). ECU1 now requires increasing the precision to 0.01 km / h, resulting in an increase in length to 16 bits. The ECU change set includes the modified signal definition attributes (new length 16 bits, new precision 0.01) and the same logical transmit / receive attributes.

[0119] Specifically, step 1 is an atomic operation conversion. The generated instruction is: MODIFY_SIGNAL_ATTRIBUTE(Signal_B, {new precision: 0.01, new length: 16 bits}).

[0120] For example, step 2 performs an update operation in the platform signal library. Impact analysis: Locating the packet 0x1C0 to which Signal_B belongs, the continuous area after the original start bit 16 is occupied by other signals. The increased length makes the original position unable to accommodate it, requiring a re-layout. Generating layout adjustment schemes: Scheme A (moving within the current packet): Query the free bit field in packet 0x1C0 and find that there are 16 free bits at the start bit 40, which can accommodate the signal; Scheme B (extending the packet length): Extend the packet DLC from 8 bytes to 12 bytes (the platform allows a maximum of 12 bytes), allocate the start bit 64 in the newly added byte area, with a length of 16 bits; Scheme C (migrating to other packets): Migrate Signal_B to another related packet 0x2D0, which has 16 free bits at the start bit 24. Scheme selection and library update: Submit the three candidate schemes to the external rule engine for real-time verification and conflict arbitration. The rule engine returns that the verification is successful and selects scheme A. Update the signal position attribute of Signal_B in the platform signal library, changing the start byte from 2 (start bit 16) to 5 (start bit 40); at the same time, update the precision and length in the signal definition attributes.

[0121] Specifically, ESP submits the modification signal Signal_B (wheel speed signal), and the rule engine generates three layout adjustment schemes. Scheme A: Move to the start bit 40 within the current message 0x1C0, with a length of 16; Scheme B: Extend the length of message 0x1C0 to 12 bytes, add a new area start bit 64, with a length of 16; Scheme C: Migrate to message 0x2D0, with a start bit 24 and a length of 16.

[0122] For example, the rules engine loads the MODIFY operation rule chain. Rule 1 is the impact analysis rule (simplified; the rules engine already provides impact analysis, so we directly proceed to layout detection); Rule 2 is the physical layout conflict detection rule. Scheme A: Starting bit 40, query the occupancy map of the 0x1C0 bit field in the message; this position is free; no reserved bits are occupied; the load rate increases from 60% to 70%, meeting the requirements, and returns SUCCESS. Scheme B: Starting bit 64, query the platform's reserved bit table; starting bits 64~79 are found to be a diagnostic reserved area, occupying reserved bits, and returns CONFLICT, eliminating Scheme B. Scheme C: Starting bit 24, the 0x2D0 bit field in the message is free; no reserved bits are occupied; the load rate increases from 50% to 62.5%, and returns SUCCESS.

[0123] Specifically, there are two schemes (A and C) that pass the layout detection, and the meta-arbitrator intervenes to make a decision. The meta-arbitrator decides: based on the "prioritize minimum disturbance" strategy, scheme A only moves the signal without changing the packet's ownership, resulting in minimal disturbance; scheme C requires migrating the packet, which may affect other dependencies. Scheme A is selected, and the reason "minimum disturbance priority" is recorded. The arbitration result is output: scheme A is selected, and Signal_B is updated to start bit 40, length 16, and precision 0.01. The arbitration result yields the target increment matrix.

[0124] For example, in step 3, matrix merging and output, based on the updated incremental matrix of the platform signal library (target incremental matrix), the target incremental matrix is ​​integrated with the first communication matrix (original communication matrix) to generate the merged communication matrix for the current vehicle model. The merged communication matrix includes the modified Signal_B and its new attribute set, and carries the source requirement label "EPS".

[0125] Example 3: DELETE_SIGNAL Operation (Deletion Signal, Feasibility Verification). The deletion signal is Signal_C, and the rule engine loads the DELETE operation rule chain. The DELETE_SIGNAL operation (deletion signal, platform library deactivation flag) submits the deletion request to an external rule engine for feasibility verification. The rule engine verifies that the signal is still referenced by other vehicle models and returns "not feasible." Based on the platform policy, it is decided not to completely delete the signal from the platform library, but instead to mark it as deactivated in the application context of the current vehicle model, releasing the message bit field resources it occupies in the current vehicle model. The definition of Signal_C in the platform library remains unchanged.

[0126] Specifically, Step 1 involves atomic operation transformation, generating the instruction: DELETE_SIGNAL(Signal_C). Step 2 involves rule engine verification. The rule engine loads the DELETE operation rule chain and executes the deletion feasibility rule: verifying whether Signal_C exists in the current vehicle model project: it exists; checking whether there are other items in the current vehicle model that depend on Signal_C: the query finds that this signal is only used for instrument display in this vehicle model and has no other dependent references; the rule returns SUCCESS. Step 3 involves executing a deactivation operation. Based on the rule engine's SUCCESS result, the rule engine marks Signal_C as "deactivated" in the application context of the current vehicle model, releasing the message bit field resources it occupies in the current vehicle model. The definition of Signal_C in the platform library remains unchanged and continues to be used by other vehicle models. Step 4 involves outputting a merged communication matrix. The merged communication matrix records the status of Signal_C as "deactivated" and includes a source requirement label.

[0127] The multi-source vehicle communication requirement merging verification and arbitration method provided in this embodiment includes: obtaining a candidate scheme set of incremental matrices based on atomic operation parsing; determining the operation type identifier of the candidate scheme set of incremental matrices; dynamically loading a predefined rule chain according to the operation type identifier; performing real-time verification and conflict arbitration on the candidate scheme set of incremental matrices based on the rule chain to obtain a target incremental matrix; and integrating the target incremental matrix with the original communication matrix to generate a merged communication matrix. This embodiment dynamically loads a predefined rule chain according to the operation type identifier of atomic operations through rule chain scheduling, executes each rule and returns a status code, and drives the process control through status codes. This significantly improves the flexibility and scalability when facing different operation types, and can automatically and differentiatedly execute processing strategies according to the different nature and severity of conflicts, thereby improving the automation level of conflict handling.

[0128] Reference Figure 4 , Figure 4 This is a structural block diagram of an embodiment of the multi-source vehicle communication requirement merging verification and arbitration system of the present invention. Figure 4 As shown, the multi-source vehicle communication requirement merging verification and arbitration system includes:

[0129] The candidate solution acquisition module 10 is used to acquire a set of incremental matrix candidate solutions based on atomic operation parsing;

[0130] The rule dynamic loading module 20 is used to determine the operation type identifier of the incremental matrix candidate scheme set and dynamically load a predefined rule chain according to the operation type identifier;

[0131] The verification and conflict arbitration module 30 is used to perform real-time verification and conflict arbitration on the candidate scheme set of the incremental matrix based on the rule chain to obtain the target incremental matrix.

[0132] The communication matrix merging module 40 is used to integrate the target incremental matrix with the original communication matrix to generate a merged communication matrix.

[0133] Specifically, the multi-source vehicle communication requirement merging and verification arbitration system proposed in this embodiment may include a rule chain scheduler, a state machine, and a meta-arbitrator. The rule chain scheduler dynamically loads predefined rule chains according to atomic operation types, executes each rule sequentially, and returns a status code (SUCCESS / CONFLICT / NEED_HUMAN). The state machine controls the flow based on the status code: SUCCESS continues to the next rule; CONFLICT triggers backtracking and retry, suspends manual intervention, or forces continuation; NEED_HUMAN pauses the process and waits for manual intervention. When multiple candidate solutions or conflicting suggestions exist between rules, the meta-arbitrator makes the final decision based on the project strategy matrix. After all rules have been executed, the arbitration-tried design result is output, along with a full-process execution trajectory log.

[0134] The multi-source vehicle communication requirement merging and arbitration system provided in this embodiment dynamically loads predefined rule chains according to atomic operation types through a rule chain scheduler, executes each rule sequentially, and returns a status code (SUCCESS / CONFLICT / NEED_HUMAN). The state machine controls the flow based on the status code: SUCCESS continues to the next rule; CONFLICT triggers backtracking and retry, suspends manual intervention, or forces continuation; NEED_HUMAN pauses the process and waits for manual intervention. When multiple candidate solutions or conflicting suggestions between rules occur, the meta-arbitrator makes the final decision based on the project strategy matrix. After all rules have been executed, the arbitration-adjusted design result is output, along with a full-process execution trajectory log.

[0135] In addition, for technical details not described in detail in this embodiment of the multi-source vehicle communication requirement merging verification and arbitration system, please refer to the multi-source vehicle communication requirement merging verification and arbitration 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 multi-source vehicle communication requirement merging verification arbitration 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 multi-source vehicular communication requirement merging verification and arbitration 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 multi-source vehicle communication requirement merging verification arbitration 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 merging, verifying, and arbitrating multi-source vehicle communication requirements, characterized in that, include: Obtain the candidate scheme set of incremental matrix based on atomic operation analysis; Determine the operation type identifier of the incremental matrix candidate scheme set, and dynamically load the predefined rule chain according to the operation type identifier; Based on the rule chain, the candidate scheme set of the incremental matrix is ​​verified and conflict arbitration is performed in real time to obtain the target incremental matrix; The target incremental matrix is ​​integrated with the original communication matrix to generate a merged communication matrix.

2. The method according to claim 1, characterized in that, The step of performing real-time verification and conflict arbitration on the candidate scheme set of the incremental matrix based on the rule chain to obtain the target incremental matrix includes: The rules are executed on the incremental matrix candidate scheme set based on the rule chain, and a status code and execution details are returned after each rule is executed. Based on the status code, rule chain verification and arbitration are performed to generate an arbitration-based design implementation increment matrix. The target incremental matrix is ​​obtained by implementing the incremental matrix based on the arbitration-adjusted design.

3. The method according to claim 2, characterized in that, The step of performing rule chain verification and arbitration based on the status code includes: If the status code is successful, execute the next rule; When the status code is conflicting, a predefined strategy is triggered; wherein, the predefined strategy includes backtracking and retrying, suspending manual intervention, and forcing continuation; When the status code indicates that manual intervention is required, the process is paused and a notification is triggered.

4. The method according to claim 2, characterized in that, The operation type identifiers include: adding a signal, modifying signal attributes, and deleting a signal; the predefined rule chains include: adding a signal operation rule chain, modifying signal attributes operation rule chain, and deleting a signal operation rule chain.

5. The method according to claim 4, characterized in that, The step of executing rules on the incremental matrix candidate solution set based on the rule chain, and returning a status code and execution details after each rule is executed, includes: When the operation type is identified as a new signal, the rules are executed on the incremental matrix candidate scheme set according to the order of the new signal operation rule chain, and a status code and execution details are returned after each rule is executed; wherein, the new signal operation rule chain includes: signal naming compliance rules, signal-message matching decision rules, and physical layout conflict detection rules.

6. The method according to claim 4, characterized in that, The step of executing rules on the incremental matrix candidate solution set based on the rule chain, and returning a status code and execution details after each rule is executed, includes: When the operation type is identified as modifying signal attributes, the rules are executed on the incremental matrix candidate scheme set according to the order of the operation rule chain for modifying signal attributes, and a status code and execution details are returned after each rule is executed; wherein, the operation rule chain for modifying signal attributes includes: impact analysis rules and physical layout conflict detection rules.

7. The method according to claim 4, characterized in that, The step of executing rules on the incremental matrix candidate solution set based on the rule chain, and returning a status code and execution details after each rule is executed, includes: When the operation type is identified as a deletion signal, rules are executed on the incremental matrix candidate scheme set based on the deletion signal operation rule chain, and a status code and execution details are returned after each rule is executed; wherein, the deletion signal operation rule chain includes: deletion feasibility rules.

8. The method according to claim 2, characterized in that, The method further includes: When multiple candidate solutions or conflicting suggestions arise during rule chain execution, a comprehensive score is obtained based on a project-level strategy matrix. The project-level strategy matrix includes: functional coupling, bus load balancing, platform reuse potential, and historical design inertia. The solution with the highest score is output as the arbitration result based on the scoring results, so as to generate the post-arbitration design implementation increment matrix.

9. The method according to any one of claims 1 to 8, characterized in that, The process of obtaining the candidate scheme set of incremental matrix based on atomic operation analysis includes: Obtain change request information and abstract the change request information into atomic operation instructions; wherein, the atomic operation instructions include add signal instructions, modify signal attribute instructions, and delete signal instructions; Based on the platform signal library, platform context-aware differential processing is performed on each atomic operation instruction to generate candidate implementation results of the atomic operation; An incremental matrix candidate scheme set is generated based on the candidate implementation results.

10. A multi-source vehicle communication requirement merging verification and arbitration system, characterized in that, include: The candidate solution acquisition module is used to acquire a set of incremental matrix candidate solutions based on atomic operation parsing; The rule dynamic loading module is used to determine the operation type identifier of the incremental matrix candidate scheme set and dynamically load the predefined rule chain according to the operation type identifier. The verification and conflict arbitration module is used to perform real-time verification and conflict arbitration on the candidate scheme set of the incremental matrix based on the rule chain to obtain the target incremental matrix. The communication matrix merging module is used to integrate the target incremental matrix with the original communication matrix to generate a merged communication matrix.

11. 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 9.

12. 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 9.

Images