A method and device for checking software defects of an automobile instrument based on a large language model

Abstract

The application relates to a large language model-based automobile instrument software defect checking method and device, and the method comprises the following steps: obtaining current target information in a software integration process and corresponding historical target information; performing difference comparison on the current target information and the historical target information to determine difference characteristic data; calling a pre-trained language model to perform semantic analysis on the difference characteristic data to identify change content corresponding to the difference characteristic data and potential risks; and outputting a checking report for software defects based on the result of the semantic analysis. By introducing an intelligent agent into automobile instrument software, the application can efficiently identify difference points and change area influences in a binary file, improve checking accuracy and efficiency, and reduce software quality risks.

Description

Technical Field

[0001] This invention belongs to the field of automotive instrument software technology, specifically relating to a method and apparatus for defect inspection of automotive instrument software based on a large language model. Background Technology

[0002] In automotive instrument cluster software development, unexpected changes to the integrated development environment (IDE) often lead to unexpected changes in the final integrated software, resulting in defects being introduced into the final product. Traditional automotive instrument cluster software integration environments are deployed using Jenkins, but Jenkins environment changes are often poorly managed, requiring only periodic human verification and checks. Furthermore, the automated integration software version for automotive instrument clusters is a binary file, making direct human verification difficult and time-consuming. To avoid anomalies in the final automotive instrument cluster software version caused by changes in the automated compilation environment or accidental writes during development, a method based on a large language model is designed to check for environment changes and software version anomalies. Summary of the Invention

[0003] To address the shortcomings of traditional Jenkins-based automated integration environments, such as insufficient inspection and the inability to efficiently verify whether the integrated instrument cluster software version matches expectations, and to improve the accuracy of automotive instrument cluster software inspection, this invention provides a method for inspecting automotive instrument cluster software defects based on a large language model. The method includes: acquiring current target information and corresponding historical target information during the software integration process; comparing the current target information with the historical target information to determine difference feature data; calling a pre-trained language model to perform semantic analysis on the difference feature data to identify the changes and potential risks corresponding to the difference feature data; and outputting an inspection report for software defects based on the results of the semantic analysis.

[0004] In some embodiments of the present invention, the target information includes: configuration information of the integrated environment; and / or version data of the software integration.

[0005] Furthermore, obtaining the configuration information of the integration environment includes: obtaining a snapshot of the current integration environment's state when a software integration request is triggered; and using the pre-trained language model to extract features from the state snapshot to obtain structured current configuration parameters.

[0006] Furthermore, the difference comparison includes comparing the current configuration parameters with historical configuration parameters extracted from historical snapshots to determine the points of change in the environment configuration.

[0007] Furthermore, obtaining the version data of the integrated software includes: obtaining the currently integrated binary target file and the historical binary file of the previous integration.

[0008] In some embodiments of the present invention, determining the difference feature data includes: performing a differential comparison between the binary target file and historical binary files to determine the difference value and the address region to which the difference value belongs.

[0009] A second aspect of the present invention provides an automotive instrument software defect inspection device based on a large language model, comprising: an acquisition module for acquiring current target information and corresponding historical target information during the software integration process; a determination module for comparing the current target information and the historical target information to determine difference feature data; an identification module for calling a pre-trained language model to perform semantic analysis on the difference feature data to identify the changes and potential risks corresponding to the difference feature data; and an output module for outputting an inspection report on software defects based on the results of the semantic analysis.

[0010] A third aspect of the present invention provides an electronic device comprising: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the automotive instrument software defect inspection method based on a large language model provided in the first aspect of the present invention.

[0011] In a fourth aspect, the present invention provides a computer-readable medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the automotive instrument software defect inspection method based on a large language model provided in the first aspect of the present invention.

[0012] The beneficial effects of this invention are: An integration inspection agent is introduced to link the environment inspection process with the software version baseline. This standardizes and ensures the traceability of the inspection process, fundamentally guaranteeing the rigor of integration environment inspections. By embedding inspection activities into the integration process through the integration inspection agent, inspection and integration operations are executed synchronously. This significantly improves inspection efficiency, avoids the lag issues of previous manual inspections, and enhances the real-time performance and reliability of the integration process.

[0013] Leveraging the extensive knowledge base and deep reasoning capabilities provided by Large Language Models (LLM), this technology assists the integrated inspection agent in analysis and judgment. It overcomes the limitations of traditional human experience, significantly improving the accuracy of inspections and the coverage of problem detection.

[0014] Software version checking has the following beneficial effects: For automotive instrument cluster software versions, because they are binary files, there has been a lack of effective methods in the industry to ensure that no unexpected changes have been integrated into the software version. This method introduces a software version checking agent, enabling efficient and accurate checking of binary files.

[0015] Automotive instrument cluster software binary files are large in size, and when significant changes are made, human inspection often consumes a significant amount of time and is not always accurate. By introducing LLM (Local Management Model) into the agent, differences and the impact of changes in the binary file can be efficiently identified, greatly improving the accuracy of the inspection and reducing software quality risks. The entire software versioning process is fully automated, improving efficiency while minimizing inaccuracies in inspection results caused by human error. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the basic process of the automotive instrument software defect inspection method based on a large language model in some embodiments of the present invention. Figure 2 This is a schematic diagram illustrating the specific process of the automotive instrument software defect inspection method based on a large language model in some embodiments of the present invention. Figure 3 This is a schematic diagram of the structure of an automotive instrument software defect inspection device based on a large language model in some embodiments of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device in some embodiments of the present invention. Detailed Implementation

[0017] The principles and features of the present invention are described below with reference to the accompanying drawings. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0018] Example 1 refer to Figure 1 and Figure 2 In a first aspect, a method for inspecting defects in automotive instrument software based on a large language model is provided, comprising: S100. acquiring current target information and corresponding historical target information during the software integration process; S200. comparing the current target information and the historical target information to determine difference feature data; S300. calling a pre-trained language model to perform semantic analysis on the difference feature data to identify changes and potential risks corresponding to the difference feature data; S400. outputting an inspection report for software defects based on the results of the semantic analysis.

[0019] In step S100 of some embodiments of the present invention, current target information and corresponding historical target information are obtained during the software integration process; Specifically, when Jenkins automatic integration is manually triggered, agent1 is also triggered simultaneously. Agent1 captures a snapshot of the current Jenkins environment. Agent1 then sends the environment snapshot to LLM for image analysis to obtain the Jenkins environment configuration information. Agent1 retrieves the environment from the most recently integrated environment from a specified directory. Agent1 calls LLM to perform image analysis and obtains the previous Jenkins environment configuration information.

[0020] In step S100 or S200 of some embodiments of the present invention, the target information includes: configuration information of the integrated environment; and / or version data of the software integration.

[0021] Furthermore, obtaining the configuration information of the integration environment includes: obtaining a snapshot of the current integration environment's state when a software integration request is triggered; and using the pre-trained language model to extract features from the state snapshot to obtain structured current configuration parameters.

[0022] Furthermore, the difference comparison includes comparing the current configuration parameters with historical configuration parameters extracted from historical snapshots to determine the points of change in the environment configuration.

[0023] Specifically, agent1 compares the environmental variable information from the two iterations, identifies the changes, and provides a summary of these changes. Based on this information, it performs a potential impact analysis for the LLM team and offers recommendations. It also clearly identifies the risks associated with the changes.

[0024] Furthermore, obtaining the version data of the integrated software includes: obtaining the currently integrated binary target file and the historical binary file of the previous integration.

[0025] In step S200 of some embodiments of the present invention, determining the difference feature data includes: performing a differential comparison between the binary target file and a historical binary file to determine the difference value and the address region to which the difference value belongs.

[0026] Specifically, agent2 retrieves the previous software integration version from the SVN server. Based on the two integration versions, agent2 performs a differential comparison between them.

[0027] In step S300 of some embodiments of the present invention, a pre-trained language model is invoked to perform semantic analysis on the differential feature data in order to identify the changes and potential risks corresponding to the differential feature data. Specifically, based on the comparison information, LLM obtains the differential content and difference region information. Based on the changed content and difference region information obtained from the differential comparison, and combined with the binary address region division information in the knowledge base, a change content and impact report is generated.

[0028] In step S400 of some embodiments of the present invention, an inspection report on software defects is output based on the results of the semantic analysis.

[0029] Specifically, the generated change details and impact report are output to a designated directory, and a notification is sent to the designated developers via email. The developers then analyze the change report and impact analysis report against the anticipated changes to ultimately confirm whether the current version has any defects.

[0030] It is understood that agent1 and agent2 in this disclosure are only functional divisions. In reality, based on the reasoning capabilities of the large model, the two can also be integrated without affecting its implementation.

[0031] Example 2 refer to Figure 3 In a second aspect, the present invention provides an automotive instrument software defect inspection device based on a large language model, comprising: an acquisition module for acquiring current target information and corresponding historical target information during the software integration process; a determination module for comparing the current target information and the historical target information to determine difference feature data; an identification module for calling a pre-trained language model to perform semantic analysis on the difference feature data to identify the changes and potential risks corresponding to the difference feature data; and an output module for outputting an inspection report on software defects based on the results of the semantic analysis.

[0032] Furthermore, the determining module includes: a comparison unit for performing differential comparison between the binary target file and historical binary files; and a determining unit for determining the difference value and the address region to which the difference value belongs.

[0033] refer to Figure 2 In one specific embodiment, suppose an automaker is developing a new intelligent car dashboard system that integrates multiple functions such as speed display, fuel consumption monitoring, navigation information, and vehicle status monitoring. The defect detection method based on this disclosure is used for detection, and the entire detection process is divided into three main parts: software version check (agent2), automated integration process, and Jenkins environment check (agent1).

[0034] 1. Initial Phase: The process officially begins when a new software version is ready to enter the testing phase. At this time, the system will automatically trigger a series of check tasks to ensure that all necessary preparations have been completed.

[0035] 2. Retrieve the current software integration version in SVN: The system first retrieves the latest software integration version number from the SVN repository. For example, the current version is v1.5.0. Simultaneously, the system also retrieves the version number of the last integration, which is v1.4.9.

[0036] 3. Retrieve the previous software integration version in SVN: By comparing the two version numbers, the system can determine if new code has been committed. If discrepancies exist, further analysis of the specific changes is required.

[0037] 4. Use LLM to compare the two versions: Using a Large Language Model (LLM), the system performs in-depth analysis of the differences between the two versions. The LLM can identify newly added functional modules, modified logical branches, and removed redundant code. For example, in version 1.5.0, the developers added a new fuel consumption calculation algorithm and optimized the refresh rate of navigation information. These changes are accurately captured and recorded by the LLM.

[0038] 5. Obtain the comparison difference content and the regions of difference: LLM generates a detailed differential report, listing all changed file paths and their specific contents. For example, in the file ` / src / main / java / com / car / dashboard / SpeedDisplay.java`, three code snippets were modified, involving adjustments to the speed unit conversion logic. Furthermore, LLM also identifies potential risk points, such as non-standard variable naming or function call order that could lead to deadlocks.

[0039] 6. Utilize LLM to analyze the content and purpose of changes based on differential information and binary file region block information: Furthermore, LLM combines the decompiled results of binary files to conduct in-depth analysis of the intent behind each change. For example, it might discover that although a function's functionality hasn't directly changed, its internal loop structure has been refactored to improve execution efficiency.

[0040] For complex multithreaded operations, LLM can also predict potential race conditions and propose corresponding solutions.

[0041] 7. Output change reports and analysis reports: Finally, the system generates a complete change report and analysis report, including all change details, risk assessment, and improvement recommendations. This report will serve as the basis for subsequent testing.

[0042] 8. Add tags after software modification: After developers complete code modifications, they will tag the new version in SVN. For example, version v1.5.0 will be tagged with "release_1.5.0" for easy tracking and management.

[0043] Manually specifying the current version and triggering integration: After the project manager or test lead confirms that everything is correct, they manually start the automated integration process. This step ensures that only approved versions will enter the formal integration phase.

[0044] Jenkins begins automatic integration: After receiving the command, the Jenkins server immediately starts the build task. It will sequentially perform a series of operations such as compiling, linking, and packaging, ultimately generating a deployable software package.

[0045] During this process, Jenkins will also run unit tests and integration tests to verify that each component is working properly.

[0046] Integration complete and software version generated: After all tests pass, Jenkins successfully generates a new software version file and uploads it to the designated SVN directory. Simultaneously, Jenkins generates a detailed build log, recording the results and time taken for each step.

[0047] Upload to the designated SVN directory: The new version file is securely stored in the SVN repository for other team members to download and use. Simultaneously, relevant metadata (such as version number, build time, and responsible party) is also updated synchronously.

[0048] 9. Jenkins environment check (agent1) Start by capturing a snapshot of the current Jenkins environment: Before each integration, the system will automatically capture a snapshot of the current Jenkins environment. This snapshot includes, but is not limited to: JDK version, Maven configuration, plugin list, network connection status, etc.

[0049] Snapshot data is stored in an encrypted manner to prevent unauthorized access.

[0050] LLM analyzes the parameters in the snapshot: It analyzes each parameter in the snapshot to determine if there are any anomalies or incompatibilities. For example, if it detects that the JDK version is lower than the recommended value, LLM will issue a warning. Furthermore, LLM can predict potential future problems based on historical data and take preventative measures in advance.

[0051] Read the snapshot of the last integration environment: The system retrieves the environment snapshot from the database at the time of the last integration and compares it with the current snapshot.

[0052] By comparing the differences between the two, the cause of environmental changes can be quickly identified. For example, if a plugin version is upgraded, its impact on existing functionality needs to be assessed.

[0053] LLM analyzes the parameters from the previous environment snapshot: It performs a deep analysis of the previous snapshot to identify key parameters and potential risks. Combined with information from the current snapshot, LLM gains a more comprehensive understanding of the overall integration environment's changing trends.

[0054] LLM compares the parameter changes in the two tests and provides explanations of the changes: After comprehensive analysis, the LLM will generate a detailed change notification document, clearly indicating which parameters have changed, the reasons for the changes, and the potential consequences. For example, if it discovers that the Maven dependency library version has been updated, the LLM will alert the team to check for compatibility issues.

[0055] Based on the changes, the LLM will provide suggestions and risks regarding potential impacts: According to the change notes, the LLM will offer a series of targeted recommendations. For example, it may recommend adding regression test cases for the new version's dependency libraries; or it may suggest temporarily disabling certain high-risk functional modules until further verification before re-enabling them.

[0056] At the same time, LLM will assess the level of risk that these changes may cause and provide corresponding response strategies.

[0057] Example 3 refer to Figure 4 A third aspect of the present invention provides an electronic device comprising: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the automotive instrument software defect inspection method based on a large language model according to the first aspect of the present invention.

[0058] Electronic device 500 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 501, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 502 or a program loaded from storage device 508 into random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of electronic device 500. The processing unit 501, ROM 502, and RAM 503 are interconnected via bus 504. An input / output (I / O) interface 505 is also connected to bus 504.

[0059] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 508 including, for example, hard disks; and communication devices 509. Communication device 509 allows electronic device 500 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 An electronic device 500 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 4 Each box shown can represent a device or multiple devices as needed.

[0060] Specifically, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 509, or installed from a storage device 508, or installed from a ROM 502. When the computer program is executed by a processing device 501, it performs the functions defined in the methods of embodiments of this disclosure. It should be noted that the computer-readable medium described in embodiments of this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In embodiments of this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In embodiments of this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0061] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable medium carries one or more computer programs, which, when executed by the electronic device, cause the electronic device to: Computer program code for performing the operations of embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages—such as Java, Smalltalk, C++, and Python—and conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can 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 remote computers, the remote computer can 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 can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0062] 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 this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0063] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for detecting defects in automotive instrument software based on a large language model, characterized in that, include: Obtain current target information and corresponding historical target information during the software integration process; The current target information and the historical target information are compared to determine the difference feature data; A pre-trained language model is invoked to perform semantic analysis on the differential feature data in order to identify the changes and potential risks corresponding to the differential feature data; Based on the results of the semantic analysis, an inspection report on software defects is output.

2. The method for detecting defects in automotive instrument software based on a large language model according to claim 1, characterized in that, The target information includes: Configuration information for the integrated environment; and / or Software integration version data.

3. The method for detecting defects in automotive instrument software based on a large language model according to claim 2, characterized in that, The process of obtaining the configuration information of the integrated environment includes: When a software integration request is triggered, a snapshot of the current integration environment's state is obtained; The pre-trained language model is used to extract features from the state snapshot to obtain structured current configuration parameters.

4. The method for detecting defects in automotive instrument software based on a large language model according to claim 3, characterized in that, The difference comparison includes: The current configuration parameters are compared with the historical configuration parameters extracted from historical snapshots to determine the points of change in the environment configuration.

5. The method for detecting defects in automotive instrument software based on a large language model according to claim 2, characterized in that, The acquisition of software integration version data includes: Retrieves the currently integrated binary target file and the historical binary files from the previous integration.

6. The method for detecting defects in automotive instrument software based on a large language model according to claim 1, characterized in that, The data used to determine the differences in features include: The binary target file is compared with the historical binary file using a differential comparison method to determine the difference value and the address region to which the difference value belongs.

7. A device for detecting defects in automotive instrument software based on a large language model, characterized in that, include: The acquisition module is used to acquire the current target information and the corresponding historical target information during the software integration process; The determination module is used to compare the current target information with the historical target information to determine the difference feature data; The identification module is used to call a pre-trained language model to perform semantic analysis on the differential feature data in order to identify the changes and potential risks corresponding to the differential feature data. The output module is used to output an inspection report on software defects based on the results of the semantic analysis.

8. The automotive instrument software defect inspection device based on a large language model according to claim 7, characterized in that, The determining module includes: The comparison unit is used to perform differential comparison between the binary target file and historical binary files; A determining unit is used to determine the difference value and the address region to which the difference value belongs.

9. An electronic device, comprising: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the automotive instrument software defect inspection method based on a large language model as described in any one of claims 1 to 6.

10. A computer-readable medium having a computer program stored thereon, wherein, When the computer program is executed by the processor, it implements the automotive instrument software defect inspection method based on a large language model as described in any one of claims 1 to 6.

Images