A method for analyzing embedded software interrupt defects based on customized rules

Abstract

The application discloses a kind of based on custom rule's embedded software interrupt defect analysis method, including steps S1: establishing the rule knowledge base of embedded software interrupt defect analysis, including the interrupt source information identification rule and interrupt defect identification rule of configurable;Step S2: through embedded software source code and relevant configuration file generation program syntax analysis tree and according to program syntax analysis tree, the module and structure analysis of embedded software are carried out;Step S3: according to the interrupt source information identification rule of step S1 and the software module and structure information of step S2, interrupt source information identification and extraction are carried out;Step S4: user is according to the interrupt source information identified and service needs, from rule knowledge base, select the interrupt defect analysis rule to be applied, new interrupt defect identification rule that meets the needs of scene is customized in combination with interrupt source information;Step S5, in combination with the identification information and rule information of step S2-S4, embedded software interrupt defect analysis is carried out and analysis report is generated.

Description

Technical Field

[0001] This invention relates to the field of embedded software testing defect analysis, and in particular to an embedded software interruption defect analysis method based on customized rules. Background Technology

[0002] Interrupt mechanisms are a crucial component of embedded software. An interrupt refers to the process of pausing the currently executing program when a critical event is encountered during program execution, setting a breakpoint, and executing the corresponding event handler. Once the emergency event is resolved, the program returns to the breakpoint to continue execution. The execution of interrupt handlers is random, and problems caused by poor interrupt design are more unpredictable and unpredictable than general software problems.

[0003] Interrupt-related problems are diverse, commonly including global resource conflicts caused by accessing critical variables, registers, and interfaces, and abnormal program states due to improper timing settings such as interrupt enabling and interrupt configuration. For example, one software found that its data port was modified simultaneously by both the main program and the interrupt service routine, leading to software mode switching failures; another software model experienced a problem where a single interrupt received multiple interrupt sources simultaneously. When interrupts arrived at the same time, the interrupt service routine prioritized responding to the highest priority interrupt, clearing the interrupt flag after the high-priority interrupt was resolved, resulting in lower-priority interrupts not being responded to. Traditional embedded software interrupt analysis largely relies on the experience of testers, lacking a complete toolchain for embedded software interrupt information identification and interrupt defect analysis, and still lacks effective analysis and support for common problems such as global resource conflicts and timing conflicts. Summary of the Invention

[0004] To overcome the shortcomings of existing technologies, this invention provides an embedded software interruption defect analysis method based on customized rules. A rule knowledge base for typical interruption problems is established based on interruption analysis-related standard requirements and typical interruption analysis problems encountered by evaluation personnel. Based on interruption source information identification rules and interruption defect identification rules, combined with program module and structural information extracted from the program syntax tree of the embedded software, embedded software interruption-related defect analysis is performed, and finally, an embedded software interruption defect analysis result report is generated.

[0005] To achieve the aforementioned objectives of the invention, the technical solution adopted to solve its technical problems is as follows:

[0006] An embedded software interruption defect analysis method based on custom rules includes the following steps:

[0007] Step S1: Establish a rule knowledge base for embedded software interrupt defect analysis, which is used to analyze and extract interrupt-related defects in embedded software. This knowledge base includes both configurable interrupt source information identification rules and configurable interrupt defect identification rules.

[0008] Step S2: Generate a program syntax analysis tree from the embedded software source code and related configuration files, and perform module and structure analysis of the embedded software based on the program syntax analysis tree;

[0009] Step S3: Based on the interrupt source information identification rules in Step S1 and the software module and structure information in Step S2, interrupt source information is identified and extracted. Users can modify and confirm the interrupt source information identification and extraction results.

[0010] Step S4: Based on the identified interruption source information and business needs, the user selects the interruption defect analysis rule to be applied from the rule knowledge base. The user can also customize new interruption defect identification rules that meet the needs of the scenario by combining the interruption source information.

[0011] Step S5: Combining the identification information and rule information from steps S2 to S4, perform embedded software interruption defect analysis and generate an embedded software interruption defect analysis report.

[0012] Furthermore, in the rule knowledge base for embedded software interruption defect analysis in step S1, each rule includes its name, category, applicable standard, description, and identification features. The identification features are determined by a logical combination of various judgment conditions and can be represented as a set of judgment condition quadruples (Li, Ti, Ci, Vi). Li is the logical combination relation identifier, with possible values ​​ranging from {logical AND, logical OR, logical NOT…}; Ti is the target value involved in the judgment, with possible values ​​ranging from {expression, program variable, program statement…}; Ci is the relational operator for the Ti judgment, with possible values ​​ranging from {contains, belongs to, greater than, equal to, less than…}; and Vi is the judgment value to be judged, which can be specified and configured by the user. If the result of combining all the judgment conditions of a rule's identification features according to the logical expression of Li is true, the rule is identified as a match.

[0013] Furthermore, the interrupt source information identification rules in the rule knowledge base of step S1 include interrupt attribute information identification rules, interrupt register information identification rules, and interrupt-related function information identification rules. Among them, interrupt attribute information includes interrupt name, interrupt vector number information, and interrupt priority information; interrupt register information includes interrupt enable register, status control register, interrupt clear register, interrupt set register, and interrupt mask register; interrupt-related function information includes not only interrupt response function, interrupt enable function, and interrupt disable function, but also the size, complexity, and calling relationship of related functions.

[0014] Furthermore, the interrupt defect identification rules in the rule knowledge base of step S1 include typical interrupt defect case rules and interrupt resource usage conflict defect rules. The typical interrupt defect case rules include interrupt nested execution rules, multiple interrupt source rules, and interrupt initialization configuration rules. The interrupt resource usage conflict defect rules include critical resource variable protection rules between different interrupt response functions and critical resource variable protection rules between interrupt response functions and the main program.

[0015] Furthermore, step S2 performs module and structure analysis of the source program based on the program syntax analysis tree, which can not only obtain module information of variables, functions, and structures in the source program, but also obtain structural information such as function call relationships and interrupt call relationships.

[0016] Furthermore, the identification and extraction of interrupt source information in step S3 includes interrupt attribute information, interrupt register information, and interrupt-related function information. Users can modify and confirm the results of interrupt source information identification and extraction obtained from the analysis, or customize interrupt source information identification rules and re-analyze based on the module and structure information of the source program in step S2.

[0017] Furthermore, in step S4, the user can select the interruption defect analysis rule to be applied from the existing rule knowledge base based on name, category, standard, and description information. Alternatively, the user can customize new rules for specific applications. Customizable rule content includes rules on the combination relationship of call order of interrupt-related functions, rules on the complexity of interrupt response functions, and rules on interrupt nesting restrictions.

[0018] Furthermore, the embedded software interruption defect analysis report described in step S5 includes basic defect information, the file name of the corresponding source program, the defect location, and defect problem statistics.

[0019] By employing the above technical solutions, this invention has the following advantages and positive effects compared with the prior art:

[0020] 1. This invention addresses the challenge of randomness and sporadic occurrence in embedded software interrupt defect analysis by using custom rules combined with program syntax trees to identify interrupt source information and analyze interrupt defect problems.

[0021] 2. The rules used in this invention are derived from the relevant standards for interruption analysis and typical problems encountered by testers in interruption analysis, providing a good interface for rule customization.

[0022] 3. This invention uses a static analysis method for program syntax tree analysis, which is independent of the software runtime environment and is easy to customize. Users can select existing rules or customize rules that meet the requirements of different source programs and usage scenarios, making it more relevant to actual applications.

[0023] 4. The method and system proposed in this invention have advantages such as good scalability, support for customized analysis in multiple ways, convenient and efficient operation, and accurate results, which play an important role in improving the efficiency of embedded software interrupt analysis. Attached Figure Description

[0024] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings:

[0025] Figure 1 This is a flowchart illustrating an embedded software interruption defect analysis method based on customized rules according to the present invention.

[0026] Figure 2 This is an example diagram of the program syntax tree in this embodiment;

[0027] Figure 3 This is an example image of the interface for adding judgment conditions to custom rules in this embodiment;

[0028] Figure 4 This is an example diagram of the interruption defect analysis report in this embodiment. Detailed Implementation

[0029] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0030] like Figure 1 As shown in the figure, this embodiment discloses an embedded software interruption defect analysis method based on customized rules, including the following steps:

[0031] Step S1: Establish a rule knowledge base for embedded software interrupt defect analysis, which is used to analyze and extract interrupt-related defects in embedded software. This knowledge base includes both configurable interrupt source information identification rules and configurable interrupt defect identification rules.

[0032] For example, for a certain C language embedded software, the key information of the interrupt source information identification rules and interrupt defect identification rules involved in the knowledge base is shown in Table 1 below:

[0033] Table 1 Examples of Rule Knowledge Bases

[0034]

[0035]

[0036] Step S2: Generate a program syntax analysis tree from the embedded software source code and related configuration files, and perform module and structure analysis of the embedded software based on the program syntax analysis tree, such as... Figure 2 As shown;

[0037] Step S3: Based on the interrupt source information identification rules in Step S1 and the software module and structure information in Step S2, interrupt source information is identified and extracted. Users can modify and confirm the interrupt source information identification and extraction results.

[0038] Step S4: Based on the identified interruption source information and business needs, the user selects the interruption defect analysis rule to be applied from the rule knowledge base. The user can also customize new interruption defect identification rules that meet the specific scenario requirements, combining the interruption source information. An example diagram showing user-defined rule conditions is shown below. Figure 3 As shown, various decision condition quadruples (Li, Ti, Ci, Vi) can be freely customized on the interface.

[0039] Step S5: Combining the identification information and rule information from steps S2 to S4, perform embedded software interruption defect analysis and generate an embedded software interruption defect analysis report. The generated analysis report may include, for example... Figure 4 As shown.

[0040] Furthermore, the rule knowledge base for embedded software interruption defect analysis in step S1 includes a rule name, classification, applicable standard, description, and identification features for each rule. The identification features are determined by a logical combination of various judgment conditions and can be represented as a set of judgment condition quadruples (Li, Ti, Ci, Vi). Li is the logical combination relation identifier, with possible values ​​ranging from {logical AND, logical OR, logical NOT…}; Ti is the target value involved in the judgment, with possible values ​​ranging from {expression, program variable, program statement…}; Ci is the relational operator for the Ti judgment, with possible values ​​ranging from {contains, belongs to, greater than, equal to, less than…}; and Vi is the judgment value to be judged, which can be specified and configured by the user. If the result of combining all the judgment conditions of a rule's identification features according to the logical expression of Li is true, the rule is identified as a match.

[0041] Furthermore, the interrupt source information identification rules in the rule knowledge base of step S1 include, but are not limited to, interrupt attribute information identification rules, interrupt register information identification rules, and interrupt-related function information identification rules. Among them, interrupt attribute information includes, but is not limited to, interrupt name, interrupt vector number information, and interrupt priority information; interrupt register information includes, but is not limited to, interrupt enable register (IER), status control register (CSR), interrupt clear register (ICR), interrupt set register (ISR), and interrupt mask register; interrupt-related function information includes not only interrupt response functions, interrupt enable functions, and interrupt disable functions, but also the size, complexity, and calling relationships of related functions.

[0042] Furthermore, the interrupt defect identification rules in the rule knowledge base of step S1 include, but are not limited to, typical interrupt defect case rules, interrupt resource usage conflict defect rules, etc. The typical interrupt defect case rules include, but are not limited to, interrupt nested execution rules, multiple interrupt source rules, interrupt initialization configuration rules, etc. The interrupt resource usage conflict defect rules include, but are not limited to, rules for protecting critical resource variables between different interrupt response functions, rules for protecting critical resource variables between interrupt response functions and the main program, etc.

[0043] Furthermore, step S2 performs module and structure analysis of the source program based on the program syntax analysis tree, which can not only obtain module information such as variables, functions, and structures of the source program, but also structural information such as function call relationships and interrupt call relationships.

[0044] Furthermore, the identification and extraction of interrupt source information in step S3 includes interrupt attribute information, interrupt register information, interrupt-related function information, etc. Users can modify and confirm the results of interrupt source information identification and extraction obtained from the analysis, or customize interrupt source information identification rules based on the module and structure information of the source program in step S2 and re-analyze.

[0045] Furthermore, in step S4, the user can select the interruption defect analysis rule to be applied from the existing rule knowledge base based on name, classification, standard, description information, etc., or customize new rules for specific applications. Customizable rule content includes, but is not limited to, rules on the combination relationship of call order of interrupt-related functions, rules on the complexity of interrupt response functions, rules on interrupt nesting restrictions, etc.

[0046] Furthermore, the embedded software interruption defect analysis report content described in step S5 includes, but is not limited to, basic defect information, the file name of the corresponding source program, the defect location, defect problem statistics, etc.

[0047] The above description is merely a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for analyzing defects in embedded software based on customized rules, characterized in that, Comprise the following steps: Step S1: Establish the rule knowledge base of embedded software interrupt defect analysis, which is used for analyzing and extracting the interrupt related defects of embedded software, and the knowledge base includes not only the interrupt source information identification rule which can be configured, but also the interrupt defect identification rule which can be configured; The rule knowledge base of embedded software interrupt defect analysis in step S1, each rule contains the name, classification, standard, description and identification characteristics of the rule, wherein the identification characteristics are determined by the logical combination of multiple judgment conditions, which is expressed as a set of judgment condition four-tuples (Li, Ti, Ci, Vi), wherein Li is the logical combination relationship identifier; Ti is the target value participating in the judgment; Ci is the relationship operator of Ti judgment; Vi is the judgment value to be judged, which can be specified and configured by the user; if the result of the combination of all judgment conditions of a rule identification characteristic according to Li logical expression is true, the rule is identified and hit; Step S2: Generate program syntax analysis tree through embedded software source code and related configuration files, and analyze the modules and structures of embedded software according to the program syntax analysis tree; Step S3: According to the interrupt source information identification rule in step S1 and the software module and structure information in step S2, the interrupt source information identification and extraction are carried out, and the user can modify and confirm the interrupt source information identification and extraction result; Step S4: The user selects the interrupt defect analysis rule to be applied from the rule knowledge base according to the identified interrupt source information and business needs, or customizes new interrupt defect identification rules that meet the needs of the scene in combination with the interrupt source information; Step S5, combined with the identification information and rule information in steps S2-S4, the embedded software interrupt defect analysis is carried out, and the embedded software interrupt defect analysis report is generated.

2. The method of claim 1, wherein, The interrupt source information identification rule in the rule knowledge base in step S1 includes interrupt attribute information identification rule, interrupt register information identification rule and interrupt related function information identification rule, wherein the interrupt attribute information includes interrupt name, interrupt vector number information and interrupt priority information; the interrupt register information includes interrupt enable register, state control register, interrupt clear register, interrupt set register and interrupt mask register; the interrupt related function information includes not only interrupt response function, interrupt enable function and interrupt close function, but also the size, complexity and calling relationship of related functions.

3. The method of claim 1, wherein the customized rule is defined by a user. The interrupt defect identification rule in the rule knowledge base in step S1 includes typical interrupt defect case rule and interrupt resource use conflict defect rule, wherein the typical interrupt defect case rule includes interrupt nesting operation rule, multiple interrupt source rule and interrupt initialization configuration rule; the interrupt resource use conflict defect rule includes key resource variable protection rule between different interrupt response functions and key resource variable protection rule between interrupt response function and main program.

4. The method of claim 1, wherein the method is characterized by: Step S2 analyzes the modules and structures of the source program according to the program syntax analysis tree, obtains the module information of variables, functions and structures of the source program, and obtains the structure information of function calling relationship and interrupt calling relationship.

5. The method of claim 1, wherein the customized rule is based on a rule set for the embedded software. The identification and extraction of the interrupt source information in step S3 includes interrupt attribute information, interrupt register information, and interrupt related function information. The user modifies and confirms the analysis result of the interrupt source information, or customizes the interrupt source information identification rule based on the module and structure information of the source program in step S2 and reanalyzes.

6. The method of claim 1, wherein the method is based on customized rules. The selection of the interrupt defect analysis rule to be applied in step S4 includes the selection of the rule from the existing rule knowledge base according to the name, classification, belonging standard, and description information of the selection rule, or the new rule customization for specific application. The new rule customization content includes the calling order combination relationship rule of the interrupt related function, the complexity rule of the interrupt response function, and the interrupt nesting restriction rule.

7. The method of claim 1, wherein the method is based on customized rules. The interrupt defect analysis report content of the embedded software in step S5 includes defect basic information, a file name corresponding to the source program, a defect position, and defect problem statistics.

Images