Automobile industry code quality automatic compliance method based on large language model

Abstract

The application discloses a kind of based on big language model's automobile industry code quality automatic compliance method, calls static code analyzer and generates violation report;Based on the multi-feature analysis algorithm of rule document, Tier1, Tier2, Tier3 are classified to the violation intelligence;For Tier1 violation, use big language model to repair three times retry iteration, automatically detect compilation error and rollback;For Tier2 violation, extract a variety of technical solutions from big language model for user selection;For Tier3 violation, adopt multi-LLM antagonistic cooperation mechanism: through Generator to generate repair scheme, Discriminator examines challenge scheme, Arbiter arbitrates conflict antagonistic iteration, realize the automatic repair of complex violation, when conflict occurs, select the optimal scheme through weighted voting algorithm.The application significantly reduces the rate of manual intervention, improves repair quality, and is low in cost and strong in universality.

Description

Technical Field

[0001] This invention relates to the field of automotive software quality assurance technology, and in particular to an automatic compliance method for automotive code quality based on a large language model. Background Technology

[0002] With the rapid development of automotive intelligence and electrification, the scale of automotive software has grown dramatically, with the amount of code in a single vehicle exceeding 100 million lines. The functional safety standard ISO 26262 requires automotive software to undergo rigorous static code analysis to eliminate potential security vulnerabilities and coding defects. However, existing technologies have the following problems:

[0003] 1. Limitations of static analysis tools;

[0004] Existing static code analysis tools (such as commercial tools like Helix QAC, Coverity, and Klocwork, and open-source tools like clang-tidy, cppcheck, and SonarQube) can automatically detect code violations, but they have the following shortcomings: High false positive rate: For complex context-sensitive violations, the tools are prone to generating false positives, increasing the cost of manual review; Detection without repair: The tools can only report the location of the violation and cannot provide automatic repair capabilities; Incomplete rule coverage: A single tool cannot cover all the rules (more than 2,000) of multiple standards such as ISO 26262, MISRA C++, CERT C++, and AUTOSAR C++.

[0005] 2. Manual repairs are costly;

[0006] Traditional code compliance processes rely heavily on manual intervention, making it difficult to fix complex violations: violations involving architectural refactoring and cross-file dependencies require the intervention of senior engineers, with a repair cycle of up to several weeks; high labor costs: for an automotive project containing 100,000 lines of code, manually fixing all violations takes an average of 3-6 months and costs hundreds of thousands of yuan; high knowledge requirements: experts with mastery of C++ language, automotive standards and specifications, and domain knowledge are needed, and such talent is scarce.

[0007] 3. The conflict between cost and flexibility in business tools;

[0008] Commercial tools are expensive: annual license fees for commercial tools such as Helix QAC can reach tens of thousands of dollars, and payment is required per seat; open source tools have weak functionality: open source tools such as clang-tidy and cppcheck are free but lack automotive industry-specific rule sets and fix suggestions; customization is difficult: existing tools are difficult to customize flexibly according to the enterprise's internal coding standards.

[0009] 4. Existing AI-assisted technologies are insufficient;

[0010] In recent years, machine learning-based code repair tools (such as DeepCode and GitHub Copilot) have emerged, but they have the following problems: lack of domain expertise: general AI models are not optimized for automotive functional safety standards; black-box decision-making: the repair suggestions of neural network models lack interpretability and are difficult to pass ISO 26262 audits; inability to handle complex violations: existing AI tools mainly handle simple syntax errors and cannot automatically handle complex violations that require architectural design decisions. Summary of the Invention

[0011] To address the shortcomings of existing technologies, the present invention aims to provide an automatic compliance method for code quality in the automotive industry based on a large language model.

[0012] To achieve the objectives of this invention, the technical solution adopted is as follows:

[0013] An automated code quality compliance method for the automotive industry based on a large language model includes the following steps:

[0014] Step 1: Call a general static code analyzer to scan the target source code file, read the contents of the target source code file, perform violation detection, and generate a violation report;

[0015] Step 2: Using a multi-feature analysis algorithm based on rule documents, each detected violation is intelligently classified. The structural features, semantic features, and code example features of the rule documents are extracted. Based on features such as the scope of modification, complexity index, and density of alternative solutions, the violations are classified into Tier 1 (local automatic repair), Tier 2 (design decision), and Tier 3 (complex architecture).

[0016] Step 3: For Tier 1 violations, use the main language model for iterative repair, implement a three-retry mechanism, check for compilation errors after each repair, and roll back and try alternative solutions if it fails.

[0017] Step 4: For Tier 2 violations, extract multiple optional technical solutions from the large language model and display a comparison of their advantages and disadvantages. Apply the corresponding remediation solution based on the user's selection.

[0018] Step 5: For Tier 3 violations, initiate the adversarial collaboration mechanism of multiple language models;

[0019] The process involves adversarial iterations: the Generator generates a fix, the Discriminator reviews and challenges it, the Generator improves the fix, and this process is repeated until convergence or the maximum number of rounds is reached. If convergence is successful, a consensus mechanism is applied. If a conflict occurs, a weighted voting algorithm is used to select the optimal solution. Otherwise, multiple LLMs vote, and the one with the most votes is selected. If there is a tie, the Arbiter forces a decision.

[0020] Step 6: Verify the repair effect and generate a final report that includes the repair success rate, change log, and manual review checklist.

[0021] Furthermore, in step 2, violations are categorized as follows: Tier 1: violations with localized repair scope, no cross-file dependencies, and a clearly defined repair pattern; Tier 2: violations with an equivalent technical solution that needs to be selected based on business logic; and Tier 3: violations requiring cross-file / module refactoring, modifications exceeding 50 lines, and lacking clear remedial measures.

[0022] Furthermore, in step 2, the multi-feature analysis algorithm includes:

[0023] Structural feature extraction: Detect whether the rule document contains a section on remedial measures, the number of code examples, whether there is a Before / After comparison, and whether there is a solution comparison table;

[0024] Semantic feature extraction: Calculate the density of explicit action verbs, the number of complexity indicator words, the density of alternative indicator words, and the degree of certainty;

[0025] Code example feature extraction: analyze the average number of lines modified, the number of files involved, changes in cyclomatic complexity, and whether a new API has been introduced;

[0026] Decision tree classification: When the following conditions are met, a system is classified as Tier 1: "has_remediation=True AND code_examples≥1 AND action_verb_density≥0.03 AND complexity_score=0 AND avg_lines_changed≤10 AND files_involved≤1"; when the following conditions are met: "alternative_density≥0.05 AND code_examples≥2 AND certainty_level<0.8"; otherwise, the system is classified as Tier 3.

[0027] Furthermore, in step 3, a three-retry mechanism is implemented: if the first repair fails, alternative and conservative solutions are automatically tried. Static analysis verification is rerun after each repair to detect compilation errors. If a compilation error is introduced, the system is immediately rolled back and marked as failed. If the violation is eliminated and no new violation is introduced, the system is marked as successful. Violations that still fail after a maximum of three attempts are downgraded to Tier 3 processing.

[0028] Furthermore, the compilation error detection algorithm is as follows: after the application is fixed, the static analyzer is rerun to generate the result file; the error messages in the result file are parsed to find messages that simultaneously satisfy level="QA_ERROR" and severity="9"; if at least one message that meets the conditions is detected, it is determined to be a compilation error, and a rollback operation is immediately performed; the rollback operation includes: undoing all code changes made in this fix, rerunning the analysis to verify that the rollback was successful, and updating the violation tracking table to mark this attempt as failed.

[0029] Furthermore, in step 5, the adversarial iterative process is as follows:

[0030] 5.1 The Generator analyzes the violation and proposes an initial remediation plan A;

[0031] 5.2 The Discriminator reviews Option A and identifies potential problems;

[0032] 5.3, Based on the challenge and improvement plan from the Discriminator, the Generator proposes a repair plan B;

[0033] 5.4 The Discriminator continues to review Option B, raising new challenges or accepting the option;

[0034] 5.5 Repeat steps 5.3-5.4, for a maximum of N rounds of confrontation;

[0035] 5.6. Stop the adversarial process when the convergence conditions are met: the Discriminator accepts the solution; the improvement of the solution is less than 10% for two consecutive rounds; the maximum number of iterations N is reached; when different solutions are still generated after multiple LLM adversarial processes, the optimal solution is selected by a weighted voting algorithm.

[0036] Furthermore, the weighted voting algorithm scoring formula is: score = successful compilation (30 points) + violation elimination (30 points) + (20 - number of new violations × 5) + max(0, 10 - cyclomatic complexity) + LLM confidence × 10; where successful compilation and violation elimination are necessary conditions, and solutions that do not meet these conditions are eliminated; after scoring, the solutions are sorted in descending order. If the highest score is ≥ 80 and the difference between the highest score and the second highest score is > 10, the solution is adopted directly; otherwise, multiple LLM voting is initiated to select the solution with the most votes. If the voting is tied, Arbiter makes a mandatory decision.

[0037] Furthermore, the tie-breaking mechanism is as follows: when the three LLMs each receive one vote for each solution, Arbiter will execute a mandatory decision: input all candidate solutions and their scores, advantages and disadvantages analysis, and automotive standard compliance; conduct a comprehensive evaluation in conjunction with the special requirements of automotive safety-critical systems; output the final selected solution and detailed decision basis; the decision confidence level is marked as 0.80-0.90, and if the confidence level is <0.85, it is recommended to transfer it to the manual review queue.

[0038] Furthermore, in step 6, the generated final report includes the following statistics: repair success rate categorized by Tier level; repair change log: code for each repair, repair basis, and verification results; manual review checklist: listing all violations that failed to be automatically repaired in Tier 3, including failure reason analysis, attempted solutions, and suggested manual repair directions.

[0039] The beneficial effects of the present invention are as follows: Compared with the prior art, the present invention has the following advantages:

[0040] 1. Significantly reduces the rate of manual intervention; Tier 1 violations: 90-95% success rate of automatic repair; Tier 2 violations: users only need to select a solution, no coding required; Tier 3 violations: through multi-LLM adversarial collaboration, the success rate of automatic repair is increased from 0% to 70-75% of the traditional method; the overall rate of manual intervention is reduced from 100% to 25-30%, improving efficiency by 3-4 times;

[0041] 2. Improved repair quality; multi-LLM mutual review mechanism reduces the bias and errors of a single model; adversarial iteration ensures that the solution fully considers multiple dimensions such as compatibility, performance, and security; automatic compilation error detection and rollback mechanism avoids the introduction of new defects;

[0042] 3. Provides interpretability; the Tier grading algorithm outputs detailed feature analysis and confidence levels; each repair records complete decision-making basis (rule document reference, code examples); meets ISO 26262 requirements for tool confidence and traceability;

[0043] 4. Reduced costs; no expensive commercial tool licenses required, supports open-source static analyzers; significantly reduces the workload of manual fixes by senior engineers; compliance cycle for 100,000 lines of code projects is shortened from 3-6 months to 2-4 weeks;

[0044] 5. High versatility; supports any static analyzer (clang-tidy, cppcheck, SonarQube, etc.); covers multiple automotive standards (ISO 26262, MISRA C / C++, CERT C / C++, AUTOSAR C++); can be flexibly configured with LLM combinations (Claude, GPT, Gemini, etc.). Attached Figure Description

[0045] Figure 1 This is a flowchart of the automatic code quality compliance method for the automotive industry based on a large language model, as described in this invention.

[0046] Figure 2 This is a schematic diagram of an intelligent grading algorithm based on multi-feature analysis;

[0047] Figure 3 This is a schematic diagram of a Tier 3 multi-LLM adversarial collaboration mechanism;

[0048] Figure 4 This is a schematic diagram of the voting decision mechanism when multiple LLM adversarial processes fail to converge. Detailed Implementation

[0049] The technical solution of the present invention will be further described below with reference to the accompanying drawings and embodiments. The following embodiments are only used to more clearly illustrate the technical solution of the present invention, and should not be used to limit the scope of protection of this application.

[0050] like Figure 1 As shown, the automatic compliance method for automotive industry code quality based on a large language model, as described in this invention, includes the following steps:

[0051] Step 1: Call a general static code analyzer (clang-tidy, cppcheck, SonarQube, etc.) to scan the target source code file, read the contents of the target source code file, perform violation detection, and generate a violation report, including rule ID, message ID, number of violations, violation description, etc.

[0052] Step 2: As Figure 2 As shown, a multi-feature analysis algorithm based on rule documents is used to intelligently classify each detected violation. The structural features, semantic features, and code example features of the rule documents are extracted. Based on features such as modification scope, complexity index, and alternative density, the violations are classified into Tier 1 (local automatic repair category), Tier 2 (design decision category), and Tier 3 (complex architecture category). The classification result table containing classification criteria, confidence level, and interpretability features is output.

[0053] Tier 1 (Local Automatic Repair): Violations with a local repair scope (≤10 lines of code), no cross-file dependencies, and a clear repair pattern; Tier 2 (Design Decision): Violations with 2-4 equivalent technical solutions and requiring selection based on business logic; Tier 3 (Complex Architecture): Violations requiring cross-file / module refactoring, with a modification scope >50 lines, and lacking a clear remediation.

[0054] Step 3: For Tier 1 violations, use the main language model for iterative repair, implement a three-retry mechanism, check for compilation errors after each repair, and roll back and try alternative solutions if it fails.

[0055] Three-retry mechanism: If the first repair fails, it will automatically try alternative and conservative solutions. After each repair, it will rerun the static analysis verification to detect compilation errors (QA_ERROR level, severity=9). If a compilation error is introduced, it will be rolled back immediately and marked as failed. If the violation is eliminated and no new violation is introduced, it will be marked as successful. Violations that still fail after a maximum of 3 attempts will be downgraded to Tier 3 processing.

[0056] Step 4: For Tier 2 violations, user-guided decision-making is adopted. A large language model is used to extract multiple optional technical solutions and display their advantages and disadvantages (performance, security, maintainability). The corresponding remediation solution is applied according to the user's selection.

[0057] Step 5: For Tier 3 violations, initiate the adversarial collaboration mechanism of multiple language models;

[0058] LLM-Generator (e.g., Claude Opus): Acts as a generator, proposing solutions to fix the code; LLM-Discriminator (e.g., Gemini Pro): Acts as a discriminator, reviewing the flaws in the solutions and issuing challenges; LLM-Arbiter (e.g., Claude Sonnet): Acts as an arbitrator, synthesizing decisions and resolving conflicts.

[0059] Initialize three roles: LLM-Generator, LLM-Discriminator, and LLM-Arbiter; execute adversarial iterations: Generator generates a fix → Discriminator reviews and challenges → Generator improves the fix → repeat until convergence or the maximum number of rounds is reached; if convergence is successful, a consensus solution is applied; if conflicts arise, a weighted voting algorithm is used to select the optimal solution, with voting scoring dimensions including successful compilation, violation elimination, number of new violations, code complexity, and LLM confidence; if the highest-scoring solution is significantly different from the second-highest-scoring solution, it is adopted directly; otherwise, multiple LLMs vote, and the one with the most votes is selected; if there is a tie, the Arbiter makes a mandatory decision.

[0060] like Figure 3 As shown, the adversarial iterative process is as follows:

[0061] 5.1 The Generator analyzes the violation and proposes an initial remediation plan A;

[0062] 5.2 Discriminator reviews Option A, pointing out potential problems (such as breaking API compatibility, performance loss, or introducing new violations);

[0063] 5.3, Based on the challenge and improvement plan from the Discriminator, the Generator proposes a repair plan B;

[0064] 5.4 The Discriminator continues to review Option B, raising new challenges or accepting the option;

[0065] 5.5 Repeat steps 5.3-5.4 for a maximum of N rounds of competition (default N=5).

[0066] 5.6. The adversarial process ends when the convergence conditions are met: the Discriminator accepts the proposed solution (no new challenges); the improvement of the solution is less than 10% for two consecutive rounds; the maximum number of iterations N is reached. When multiple LLMs still produce different solutions after adversarial processes, the optimal solution is selected through a weighted voting algorithm.

[0067] Step 6: Verify the repair effect and generate a final report including the repair success rate, change log, and manual review checklist;

[0068] Calculate the repair success rate (categorized by Tier level), list the remaining violations requiring manual intervention (cases where Tier 3 repairs failed), and generate a repair change log, including the code diff, repair basis, and verification results for each repair.

[0069] The static code analyzer in Step 1 is a pluggable architecture, and the supported analyzers include, but are not limited to: open source analyzers: clang-tidy (LLVM), cppcheck, SonarQube; commercial analyzers: Helix QAC, Coverity, Klocwork; through a unified violation report parsing interface, the output of different analyzers is standardized into a unified format that includes file_path, line_number, rule_id, message_id, and description.

[0070] like Figure 2 As shown, the multi-feature analysis algorithm in step 2 includes:

[0071] Structural feature extraction: Detect the presence of a Remediation section in the rule document, the number of code examples, the presence of Before / After comparisons, and the presence of a solution comparison table;

[0072] Semantic feature extraction: Calculate the density of explicit action verbs (add, replace, check, etc.), the number of complexity indicator words (architectural, refactor, etc.), the density of alternative indicator words (alternative, option, etc.), and the degree of certainty (distribution of must / should / may modal verbs);

[0073] Code example feature extraction: analyze the average number of lines modified, the number of files involved, changes in cyclomatic complexity, and whether a new API has been introduced;

[0074] Decision tree classification: When the following conditions are met, a system is classified as Tier 1: "has_remediation=True AND code_examples≥1 AND action_verb_density≥0.03 AND complexity_score=0 AND avg_lines_changed≤10 AND files_involved≤1"; when the following conditions are met: "alternative_density≥0.05 AND code_examples≥2 AND certainty_level<0.8"; otherwise, the system is classified as Tier 3.

[0075] The Tier grading algorithm supports an adaptive learning mechanism: it initially uses a rule-based document-based heuristic grading algorithm; it collects historical repair data: for each message_id, it records the Tier level and number of repair attempts required for a successful repair; it periodically updates the grading model: when a message_id fails more than 3 times consecutively at Tier 1, it automatically adjusts the default Tier of that message_id to Tier 3; it generates a grading adjustment report for user review and confirmation; and it supports manual overriding: users can forcibly specify the Tier level for certain message_ids.

[0076] The three-retry mechanism in step 3 is as follows: First attempt: Apply the optimal standard repair solution as determined by the main language model; Second attempt: If the first attempt fails, completely roll back the first modification and apply an alternative technical solution different from the first attempt; Third attempt: If the second attempt fails, completely roll back the second modification and apply the most conservative minimal modification solution; After each attempt, check for compilation errors (QA_ERROR level messages with severity=9). If a compilation error is detected, immediately roll back and mark the attempt as failed; Violations that still fail after three attempts are automatically downgraded to Tier 3 processing.

[0077] The compilation error detection algorithm is as follows: After the application is fixed, the static analyzer is rerun to generate the result file; the error messages in the result file are parsed, and messages that simultaneously satisfy level="QA_ERROR" and severity="9" are searched; if at least one message that meets the conditions is detected, it is determined to be a compilation error, and a rollback operation is immediately performed; the rollback operation includes: undoing all code changes made in this fix, rerunning the analysis to verify that the rollback was successful, and updating the violation tracking table to mark this attempt as failed; common compilation errors include syntax errors (message 0014), type conversion errors (message 0150), and undeclared identifiers (message 0200).

[0078] like Figure 4 As shown, the convergence conditions for adversarial iteration in step 5 are as follows: Successful convergence: The Discriminator explicitly accepts the Generator's solution, and there are no new challenges; Failed convergence: The improvement of the solution is less than 10% for two consecutive rounds, or the maximum number of iterations (default N=5) is reached; When convergence is successful, the solution is applied directly; When convergence fails, the voting conflict resolution process is entered, and the optimal solution is selected by the following weighted voting algorithm.

[0079] The weighted voting algorithm scoring formula is: score = successful compilation (30 points) + violation elimination (30 points) + (20 - number of new violations × 5) + max(0, 10 - cyclomatic complexity) + LLM confidence × 10; where successful compilation and violation elimination are necessary conditions, and solutions that do not meet these conditions are eliminated; after scoring, the solutions are sorted in descending order. If the highest score is ≥ 80 and the difference between the highest score and the second highest score is > 10, the solution is adopted directly; otherwise, multiple LLM voting is initiated to select the solution with the most votes. If the vote is tied, Arbiter will force a decision.

[0080] The LLM roles are assigned as follows: LLM-Generator: Acts as a generator, proposing code fixes based on violation information and Discriminator feedback, preferably using high-performance large language models such as Claude Opus; LLM-Discriminator: Acts as a discriminator, reviewing the Generator's solution for API compatibility, performance impact, introduction of new violations, code maintainability, and automotive standard compliance, proposing challenge or acceptance solutions, preferably using diverse models such as GeminiPro to introduce different perspectives; LLM-Arbiter: Acts as an arbitrator, making the final decision in the event of a tie, comprehensively considering scores, automotive safety standards, and engineering practices, preferably using balanced models such as Claude Sonnet.

[0081] The tie-breaking mechanism is as follows: when the three LLMs each receive one vote for each solution, the LLM-Arbiter will execute a mandatory decision. The process involves inputting all candidate solutions and their scores, advantages and disadvantages analysis, and automotive standard compliance; conducting a comprehensive evaluation considering the specific requirements of automotive safety-critical systems (such as ISO 26262 ASIL level); and outputting the final selected solution and detailed decision criteria. The decision confidence level is set at 0.80-0.90; if the confidence level is <0.85, it is recommended to transfer the solution to the manual review queue.

[0082] The technical advantages of automated Tier 3 remediation compared to traditional manual remediation are as follows: Traditional method: 100% manual intervention rate (all Tier 3 violations require manual remediation by senior engineers); Automated remediation method: 25-30% manual intervention rate (70-75% success rate achieved through adversarial collaboration among multiple LLMs); Efficiency improvement: 3-4 times (compliance cycle for 100,000 lines of code is shortened from the traditional 3-6 months to 2-4 weeks); Remediation quality: The multi-LLM mutual review mechanism reduces single-model bias, and adversarial iteration ensures that the solution comprehensively considers compatibility, performance, and security.

[0083] Supports incremental and batch repair modes: Incremental mode: repairs a single file at a time, with Tier 3 violations prioritized using multi-LLM collaboration, suitable for continuous integration pipelines; Batch mode: repairs the entire codebase at once, sorting files by dependency (repairing header files first, then source files), with Tier 3 violations executed in parallel using multi-LLM collaboration to improve throughput; Both modes support resuming interrupted downloads, and the repair status of each violation (pending, in_progress, fixed, failed) is recorded through a violation tracking table.

[0084] Supports custom LLM combination strategies: Default combination: Generator=Claude Opus, Discriminator=Gemini Pro, Arbiter=Claude Sonnet; Cost-optimized combination: Uses the same medium-performance model (such as Claude Sonnet) for all models, sacrificing a small amount of accuracy for cost reduction; Performance-optimized combination: Uses the highest-performance model (such as Claude Opus) for all models to maximize the success rate of repairs; Custom combination: User configuration files specify the model name, API endpoint, and hyperparameters (temperature, max_tokens, etc.) for each role; Supports model rollback: Automatically switches to a backup model when the main model API call fails.

[0085] The adversarial iterative process includes visualization of intermediate results: each iteration outputs the Generator's solution code, reasons for fixing, and expected results; each iteration outputs the Discriminator's review report, challenges, and improvement suggestions; generates a flowchart of the adversarial process; outputs the final convergence / conflict status, voting details, and decision basis; and stores all intermediate results as structured logs for ISO 26262 audit traceability.

[0086] The final report generated in step 6 includes the following statistics: remediation success rate categorized by Tier level (Tier 1: 90-95%, Tier 2: 95-100%, Tier 3: 70-75%); remediation change log: code for each remediation, remediation basis (referenced rule documents), verification results (compilation status, violation elimination status, number of new violations); manual review checklist: listing all violations that failed to be automatically remediated at Tier 3, including failure reason analysis, attempted solutions, and suggested manual remediation directions; comprehensive manual intervention rate and efficiency improvement factor; confidence level and traceability data that meet the requirements of the ISO 26262 tool verification report.

[0087] The automotive industry code quality standards covered by the method of this invention include: ISO 26262 functional safety standard; MISRAC / C++ coding specification; CERT C / C++ safety coding standard; AUTOSAR C++ coding guidelines; and the rule mapping mechanism unifies the rules of different standards into a standard rule base, supporting joint compliance checks of multiple standards.

[0088] This invention supports integration with automotive functional safety development processes: it supports ASIL level mapping, adjusting remediation strategies based on the ASIL level (A / B / C / D) of the file containing the violation (ASIL-D level files are given priority for manual review); it generates tool confidence reports (TCL1-TCL3) compliant with ISO 26262 Part 6 requirements; it supports integration with requirements management tools such as DOORS and Polarion to establish a traceability chain from violation remediation to safety requirements; it generates remediation activity records compliant with ASPICE (Automotive SPICE) process assessment; and it supports outputting SARIF format reports, compatible with mainstream CI / CD toolchains (Jenkins, GitLab CI, GitHub Actions).

[0089] The applicant of this invention has provided a detailed description of the embodiments of the invention in conjunction with the accompanying drawings. However, those skilled in the art should understand that the above embodiments are merely preferred embodiments of the invention. The detailed description is only intended to help readers better understand the spirit of the invention and is not intended to limit the scope of protection of the invention. On the contrary, any improvements or modifications made based on the inventive spirit of the invention should fall within the scope of protection of the invention.

Claims

1. A large language model-based automobile industry code quality automatic compliance method, characterized in that, Includes the following steps: Step 1: Call a general static code analyzer to scan the target source code file, read the contents of the target source code file, perform violation detection, and generate a violation report; Step 2: Using a multi-feature analysis algorithm based on rule documents, each detected violation is intelligently classified. The structural features, semantic features, and code example features of the rule documents are extracted. Based on the scope of modification, complexity index, and density of alternative solutions, the violations are classified into Tier 1 (local automatic repair), Tier 2 (design decision), and Tier 3 (complex architecture). Tier 1: Violations with localized repair scope, no cross-file dependencies, and a clearly defined repair pattern; Tier 2: Violations with an equivalent technical solution available and requiring selection based on business logic; Tier 3: Violations requiring cross-file / module refactoring, modifications exceeding 50 lines, and lacking clear remedial measures. Multi-feature analysis algorithms include: Structural feature extraction: Detect whether the rule document contains a section on remedial measures, the number of code examples, whether there is a before-and-after comparison, and whether there is a table comparing solutions; Semantic feature extraction: Calculate the density of explicit action verbs, the number of complexity indicator words, the density of alternative indicator words, and the degree of certainty; Code example feature extraction: analyze the average number of lines modified, the number of files involved, changes in cyclomatic complexity, and whether a new API has been introduced; Decision tree classification: When the following conditions are met, a system is classified as Tier 1: "has_remediation=True AND code_examples≥1 AND action_verb_density≥0.03 AND complexity_score=0 AND avg_lines_changed≤10 AND files_involved≤1"; when the following conditions are met: "alternative_density≥0.05 AND code_examples≥2 AND certainty_level<0.8"; otherwise, it is classified as Tier 3. Step 3: For Tier 1 violations, use the main language model for iterative repair, implement a three-retry mechanism, check for compilation errors after each repair, and roll back and try alternative solutions if it fails. Step 4: For Tier 2 violations, extract multiple optional technical solutions from the large language model and display a comparison of their advantages and disadvantages. Apply the corresponding remediation solution based on the user's selection. Step 5: For Tier 3 violations, initiate the adversarial collaboration mechanism of multiple language models; The process involves adversarial iterations: the Generator generates a fix, the Discriminator reviews and challenges it, and the Generator improves the fix. This process is repeated until convergence or the maximum number of rounds is reached. If convergence is successful, a consensus mechanism is applied. If a conflict occurs, a weighted voting algorithm is used to select the optimal solution. Otherwise, multiple LLMs vote, and the one with the most votes is selected. If there is a tie, the Arbiter makes a mandatory decision. Step 6: Verify the repair effect and generate a final report that includes the repair success rate, change log, and manual review checklist.

2. The large language model-based automotive industry code quality automatic compliance method according to claim 1, characterized in that, In step 3, a three-retry mechanism is implemented: if the first repair fails, alternative and conservative solutions are automatically tried. Static analysis verification is rerun after each repair to detect compilation errors. If a compilation error is introduced, the process is immediately rolled back and marked as failed. If the violation is eliminated and no new violation is introduced, it is marked as successful. Violations that still fail after a maximum of 3 attempts are downgraded to Tier 3 processing.

3. The large language model-based automobile industry code quality automatic compliance method according to claim 2, characterized in that, The compilation error detection algorithm is as follows: after the application is fixed, the static analyzer is rerun to generate the result file; the error messages in the result file are parsed, and messages that simultaneously satisfy level="QA_ERROR" and severity="9" are searched. If at least one message matching the criteria is detected, it is determined to be a compilation error, and a rollback operation is immediately performed. The rollback operation includes: undoing all code changes that were fixed this time, rerunning the analysis to verify that the rollback was successful, and updating the violation tracking table to mark this attempt as failed.

4. The large language model-based automobile industry code quality automatic compliance method according to claim 1, characterized in that, In step 5, the adversarial iterative process is as follows: 5.1 The Generator analyzes the violations and proposes an initial remediation plan A; 5.2 The discriminator reviews scheme A and points out potential problems; 5.3 The generator proposes a repair solution B based on the challenge improvement scheme of the discriminator; 5.4 The discriminator continues to review solution B, proposing new challenges or accepting the solution; 5.5 Repeat steps 5.3-5.4, for a maximum of N rounds of confrontation; 5.6, Stop the adversarial process when the convergence condition is met: the discriminator accepts the scheme; The improvement rate of the solution in two consecutive rounds is less than 10%; The maximum number of iterations N is reached; when different solutions still emerge after multiple LLMs compete against each other, the optimal solution is selected through a weighted voting algorithm.

5. The large language model-based automotive industry code quality automatic compliance method according to claim 4, characterized in that, The weighted voting algorithm scoring formula is: score = successful compilation (30 points) + violation elimination (30 points) + (20 - number of new violations × 5) + max(0, 10 - cyclomatic complexity) + LLM confidence × 10; where successful compilation and violation elimination are necessary conditions, and solutions that do not meet these conditions are eliminated; after scoring, the solutions are sorted in descending order. If the highest score is ≥ 80 and the difference between the highest score and the second highest score is > 10, the solution is adopted directly; otherwise, multiple LLM voting is initiated to select the solution with the most votes. If the voting is tied, Arbiter will force a decision.

6. The large language model-based automotive industry code quality automatic compliance method according to claim 5, characterized in that, The tie-breaking mechanism is as follows: when the three LLMs each receive one vote for each solution, Arbiter will execute a mandatory decision: input all candidate solutions and their scores, advantages and disadvantages analysis, and automotive standard compliance; conduct a comprehensive evaluation in conjunction with the special requirements of automotive safety-critical systems; output the final selected solution and detailed decision basis; the decision confidence level is marked as 0.80-0.90, and if the confidence level is <0.85, it is recommended to transfer it to the manual review queue.

7. The automatic code quality compliance method for the automotive industry based on a large language model according to claim 1, characterized in that, In step 6, the generated final report includes the following statistics: repair success rate categorized by Tier level; repair change log: code for each repair, repair basis, and verification results; manual review checklist: a list of all violations that failed to be automatically repaired in Tier 3, including failure reason analysis, attempted solutions, and suggested manual repair directions.

Images