Method for extracting safety analysis data of aviation equipment software based on defect information

Abstract

The present invention relates to a method for extracting safety analysis data of aviation equipment software based on defect information, which comprises the following steps: step 1: obtaining defect data and determining basic defect information; step 2: processing defect problems according to basic information of software defects, and making detailed description of modification contents; step 3: forming defect IDs and constructing defect data sets according to the causes of problems in basic defect information; step 4: obtaining safety analysis data of defects based on TextRank keyword extraction technology. The present invention can fully mine and utilize information in defect data, form analysis data, give analysis directions, and provide guidance for safety analysis work; based on the safety analysis data formed after collecting defect data, combined with traditional safety analysis technology, safety analysis of software requirements is carried out in a targeted manner, software failure modes are fully and accurately identified, the analysis range is precise, and the efficiency is higher, thereby improving the overall equipment development efficiency.

Description

Technical Field

[0001] The present application relates to the technical field of software safety, and in particular to a method for extracting aviation equipment software safety analysis data based on defect information. Background Art

[0002] At present, a large amount of software defect data has been accumulated in the process of research and development, testing and verification, and upgrading and maintenance of aviation equipment software. By analyzing these defect data, it can be found that software of similar types and functions in different aviation equipment, or different versions of software in the same aviation equipment system, have great similarities and consistency in software functions, performance, interfaces, processing logic, etc., and the types and contents of software defects they contain often have something in common. On the basis of accumulating in an effective way, this similarity and consistency of defects can form repetitive and regular information, thereby giving defect data usable value. If defects can be accumulated scientifically, systematically, and completely at different stages of aviation equipment software development, forming usable data resources, and effectively utilizing and continuously iterating in subsequent work, it can reduce the recurrence of similar defects, avoid the recurrence of failures and dangers, significantly improve the efficiency of software development, effectively ensure the steady improvement of equipment safety level, and reduce the loss of life and property of users.

[0003] However, at present, 1) for the defects found, although different units use different methods to record and save, there are problems such as disordered, inconsistent, non-standard, ambiguous, difficult to understand and use directly, and more are only used for employee training, manual review, quality assurance or responsibility tracking, and have not been truly valued and used. A large number of resources are idle and wasted, and the utilization rate is extremely low. The implicit repetitive and regular information is difficult to reflect, and the relevant experience and lessons cannot be effectively transmitted and continued, and cannot play the role of inheritance as it should be. The guiding significance for subsequent work is not obvious. 2) Using traditional software safety analysis techniques, such as FTA, FMEA, FHA, etc., to carry out safety analysis work lacks effective guidelines and guidance, and the direction and pertinence of the analysis are poor. There is no special customization and focus on the external cross-linking interfaces, functional logic, working status, etc. of different software. The analysis depth is not enough, and it is difficult to discover potential valuable software failure modes or system security vulnerabilities, and it is also difficult to propose targeted control measures.

[0004] Based on this problem, the present invention proposes a method for extracting aviation equipment software safety analysis data based on defect information. The core content of this method is to collect existing defects to form standardized defect data, and on this basis, extract safety analysis data in four aspects: input, output, processing logic, and working status. This criterion can provide effective guidance for subsequent aviation equipment software safety analysis work. Summary of the invention

[0005] In order to overcome the shortcomings of the prior art, the present invention can fully mine and utilize valuable information in defect data, form analysis data, give the direction of safety analysis, and provide guidance for safety analysis work; based on the safety analysis data formed after collecting defect data, combined with traditional safety analysis technology, targeted safety analysis of software requirements is carried out, and software failure modes are fully and accurately identified. The analysis scope is precise and the efficiency is higher, which significantly improves the overall equipment development efficiency.

[0006] To achieve the above purpose, the solution adopted by the present invention is:

[0007] A method for extracting aviation equipment software safety analysis data based on defect information comprises the following steps:

[0008] Step 1: Obtain defect data and determine basic defect information;

[0009] According to the information of the aviation equipment software where the defect is located, obtain the defect data and determine the software development link where the defect is found. i and the software development process that introduces defects i :The defect data is a multi-tuple, as shown below:

[0010]

[0011] Where: Dt represents the defect dataset; id represents the unique number of the defect; csc i Indicates the software to which the defect belongs; sys i Indicates the system to which the defect belongs; md i Indicates the equipment model to which the defect belongs; ba i Indicates the batch of software products where the defect is located; cd indicates the date when the defect was collected; sc i Indicates the defect source unit; des indicates the overall description of the defect given in a semi-formal language; fd i Indicates the software development phase where defects are discovered;br i Indicates the software development phase that introduces defects; i Indicates the factors that introduce defects; tp i Indicates the type determined according to the characteristics of aviation equipment software; gd i Indicates the degree of defect; st i Indicates the defect control status derived from the defect life state; mt i Indicates the defect type involved in the defect; mc iIndicates the work product involved in the defect; ms indicates the specific content description of the defect; f indicates the software failure caused by the defect; pa indicates the impact caused by the failure;

[0012] Step 2: According to the basic information of the software defect, handle the defect problem and make a detailed description of the modification content;

[0013] Step 3: According to the cause of the problem in the basic information of the defect, a defect ID is formed and a defect data set is constructed;

[0014] Step 31: Determine the defect severity level gd based on the level of the problem, the importance of the software, and the defect levels of each level, combined with the software failure performance f caused by the defect being triggered, the impact pa caused by the failure, or the associated system hazard. i ;

[0015] Step 32: According to the software development link that introduced the defect i , factors that introduce defects i and the type tp determined according to the characteristics of aviation equipment software i The overall description of the defect des given in a semi-formal language is as follows:

[0016] des = {br i ,res i ,tp i};

[0017] Step 33: According to the date of defect collection cd and defect source unit sc i Automatically generate a defect ID; the defect ID consists of cd, sc i The eigenvalues ​​of are formed with natural numbers as follows:

[0018] id=('Dt'<<15)|(cd<<7)|(sc i <<3)|N;

[0019] Where: N represents the set of natural numbers;

[0020] Step 34: Each defect data formed in this numbering method can ensure uniqueness; according to the above steps, the basic information of the defect is collected to form unified, standardized and concise defect data, forming a complete defect data set Dt;

[0021] Step 4: Obtain security analysis data of defects based on TextRank keyword extraction technology;

[0022] Get the defect data set in step 3 and use the TextRank keyword extraction technology to extract the key defects in the defect data set, as shown below:

[0023]

[0024] Where: WS(V i ) represents the weight of defect i; V i represents the i-th defect; d represents the damping coefficient; V j Indicates the jth defect; In(V i ) represents the data set of the i-th defect; W ji Indicates the similarity between defect j and defect i; V k Indicates the kth defect; Out(V j ) represents the dataset of the j-th defect; W jk Indicates the similarity between defect j and defect k; WS(V j ) represents the weight of defect j;

[0025] The security analysis data of the defects according to the critical defects is as follows:

[0026] R mnpq ={rtp m ,rc n ,rd p ,rs q};

[0027] Where: Rl mnpq Security analysis data indicating defects; rtp m The first-level feature map representing the defect type; rc n The second-level feature map representing the defect type; rd p The third-level feature map representing the defect type; rs q The fourth level feature map representing the defect type;

[0028] Establish a mapping from defect data set Dt to analysis data Rl to realize the extraction of aviation equipment software safety analysis data.

[0029] Preferably, the software development link fd in step 1 for discovering defects i and the software development process that introduces defects i The method for obtaining the value is as follows:

[0030] The software development link where the defect was found i The values ​​of are: demand analysis and review, design analysis and review, coding self-test and review, testing and review, joint commissioning and review or maintenance; the specific values ​​are determined according to the activities when the defect is discovered, including;

[0031] The software development link that introduces defects iThe value of is: demand, design or coding stage. It is necessary to fully analyze and trace the specific manifestation of the defect when it is discovered to determine; if the defect is discovered in the demand analysis stage, then what is discovered at this time is a demand-type defect, and it can be directly located that the defect was introduced in the demand stage; if the defect is discovered in the design stage, it is necessary to analyze whether the defect can be traced back to the introduction of insufficient activities in the demand stage, or whether it is only because the activities in the design stage do not meet or meet the settings or requirements of the demand stage, that is, the requirements are not fully or correctly designed, so as to locate whether the defect is fundamentally introduced in the demand or design stage; if it is obtained from the coding and post-coding stages, similarly, analyze and trace upward in turn to see whether it can be traced back to errors in the demand, design or coding implementation, so as to locate that the defect is fundamentally introduced in the demand, design or coding stage.

[0032] Preferably, the unique number of the defect in step 1 is specifically:

[0033] The unique ID of the defect is composed as follows:

[0034] id={cd,sc i ,'No'};

[0035] Where: No represents the status of the unique number of the defect.

[0036] Preferably, in step 2, the defect problem is processed according to the basic information of the software defect, and a detailed description of the modification content is made, specifically:

[0037] Step 21: Determine the type tp determined based on the characteristics of the aviation equipment software according to the problem description and cause of the problem in the basic defect information i ; Map the defect to the defect type feature description table to determine the type determined for the characteristics of aviation equipment software tp i ;

[0038] Step 22: According to the problem description and the cause of the problem, combined with the external environment of the software operation, determine the software failure performance f caused by the defect being triggered and the impact pa caused by the failure; combined with the actual software external input and output and actual operation, analyze the defect connotation, the associated data flow, the associated functions and the abnormal output caused in the end, that is, the analysis model, and determine the failure performance f associated with the defect; combined with the external environment of the software operation, the association and the function of the device where it is located, determine the impact pa caused by the failure;

[0039] Step 23: Determine the defect control status based on the defect life cycle status i And give the work product mc involved in the defect i 、Defect type mt iand the specific content description of the defect to determine whether ms can be collected; since the collection timing of defects and the management and control of defects are throughout the entire equipment software development stage, if the current defect has been controlled and handled before collection and the handling situation has been filled in, then for the defect control status st derived from the defect life state i The characteristic is to close the i = 00, and further determine the value according to the stage at which the defect is closed. At the same time, the work product mc i and the defect type mt involved in the defect i , the specific content description of the defect ms is in the state of being able to be collected, and step 24 is executed; at this time, if the current defect has not been defect controlled before collection or there is no clear control measure, then the defect state st i The feature is opened. Since the defect is in an unhandled state, the work product mc i 、Defect type mt i The characteristics of the specific content description ms of the defect cannot be determined at this time, and it is in a state of being unable to be collected. Step 25 is skipped and the execution continues backward, and step 24 can be executed only after the three can be collected;

[0040] Step 24: If mc i 、mt i If both ms and mc can be collected, the work product mc involved in the defect is determined in turn according to the problem type and disposal measures in the basic information of the defect. i and the defect type mt involved in the defect i ;

[0041] Step 25: Based on the work product mc involved in the defect i Combined with the disposal measures in the basic defect information, determine the specific content description of the defect ms; the work product mc involved in the defect i It is strongly associated with the specific content description of the defect. The semi-automatic language is used to describe the modified content in detail, which is divided into the first type of description and the second type of description, as follows:

[0042] The first type of description is: if the modified content is a combination of requirement specifications, design specifications, ICD or other documents, that is, if mc i &(10111)! = 0; mc i If any bit in bit2 to bit0 and bit4 of is 1, the description is: delete, add and modify in chapter X, where X is the corresponding document;

[0043] The second type of description method: deleting, adding and modifying the Xc file Y functions Lm~Ln.

[0044] Preferably, in step 31, the problem level and the defect level need to satisfy a one-to-one correspondence, the problem level critical corresponds to the defect level critical, the problem level important corresponds to the defect level important, the problem level corresponds to the defect level, the problem level suggested improvement, minor and corresponding defect level minor, the software fault failure manifestation f caused by the defect being stimulated, the impact pa caused by the failure, and the associated system hazards are determined.

[0045] Preferably, in step 4, a mapping from the defect data set Dt to the analysis data Rl is established, and the specific steps are as follows:

[0046] Step 41: Establish a mapping of the defect data set Dt to the analysis data Rl classification: transform the defect type attribute tp of Dt into i The first three levels of features are mapped to rtp m rc n ,rd p , thereby determining the three-level classification of the analysis data corresponding to the defect data;

[0047] Step 42: Create a mapping from the defect data set Dt to the analysis data description: Map the defect type attribute tp of Dt to i The fourth-level feature map is a detailed description of the analysis data rs q , the mapping rule is to carry out fault flow and data flow analysis according to the software failure performance f caused by the defect being triggered, and determine the factors that should be fully considered or protected during the analysis, as each analysis data rs q , usually a one-to-many mapping relationship;

[0048] Step 43: Traverse Rl mnpq Whether the criterion already exists in the analysis data, if so, it is discarded; otherwise, it is added as a new criterion under the third-level classification of the analysis data;

[0049] Step 44: According to the above steps, the associated analysis data is extracted from the defect data that has been collected, and the safety analysis data set R1 is continuously enriched and improved.

[0050] Compared with the prior art, the present invention has the following beneficial effects:

[0051] (1) The present invention can fully mine and utilize valuable information in defect data, summarize and extract the implicit repetitiveness and regularity therein, form analytical data, and clearly give the direction of security analysis, providing analysis scope, ideas and prior knowledge guidance for subsequent security analysis work;

[0052] (2) Based on the safety analysis data formed after collecting defect data, the present invention combines traditional safety analysis technology to carry out safety analysis on software requirements in a more targeted manner, more fully and accurately identify failure modes in various software requirements, make the analysis scope more precise and specific, and make the analysis more efficient, thereby significantly improving the overall equipment development efficiency and effectively ensuring its safety level;

[0053] (3) The TextRank keyword extraction technology adopted by the present invention to process defects is an unsupervised method and can be used by only constructing a small amount of data set for training. The algorithm principle is simple and the deployment is simple, the application effect is good, and the relationship between text elements can be more fully utilized. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] Figure 1 A control block diagram of a method for extracting aviation equipment software safety analysis data based on defect information according to an embodiment of the present invention;

[0055] Figure 2 The figure is a detailed flow chart of the method for extracting software security criteria according to an embodiment of the present invention. DETAILED DESCRIPTION

[0056] Hereinafter, embodiments of the present invention will be described with reference to the drawings.

[0057] The embodiments of the present invention utilize valuable information in defect data to form analysis data and provide the direction of software security analysis. The present invention can carry out security analysis on software requirements in a more targeted manner, more fully and accurately identify failure modes in various software requirements, make the analysis scope more precise and specific, and make the analysis more efficient, thereby significantly improving the overall equipment development efficiency and effectively ensuring that the software maintains security during use. Figure 1 Shown is a control block diagram of a method for extracting aviation equipment software safety analysis data from defect information according to an embodiment of the present invention.

[0058] The embodiment of the present invention takes a piece of basic information of a software defect obtained during the testing process of a certain temperature control software as an example, as shown in Table 1, to explain how to use the original basic defect information to perform standardized collection using a collection form to form standardized defect data, thereby extracting corresponding safety analysis data. The process of collecting other aviation equipment software defects and forming corresponding safety analysis data is similar. It mainly collects a defect obtained during the testing process of a certain temperature control software using a certain method to form standardized defect data, and extracts safety analysis data for the defect from it, so as to provide targeted guidance for subsequent software safety analysis work.

[0059] Table 1 Basic information of a defect in the temperature control software of the display screen of a ground maintenance monitoring board

[0060]

[0061]

[0062] The embodiment of the present invention provides a method for extracting aviation equipment software safety analysis data from defect information. In order to prove the applicability of the present invention, the method is applied to an example, which specifically includes the following steps:

[0063] S1: Obtain defect data and determine basic defect information.

[0064] According to the information of the software where the defect is located, obtain the defect data and determine the software development link where the defect is found. i and the software development process that introduces defects i .

[0065] Software development link to find defects i :Determined based on the activities when the defect is discovered, including requirements analysis and review, design analysis and review, coding self-test and review, testing and review, joint commissioning and review, and maintenance.

[0066] Software development process that introduces defects i : It is necessary to fully analyze and trace the specific manifestation of the defect when it is discovered to determine; if the defect is discovered in the demand analysis stage, then what is discovered at this time is a demand-type defect, and it can be directly located that the defect was introduced in the demand stage; if the defect is discovered in the design stage, it is necessary to analyze whether the defect can be traced back to the introduction of insufficient activities in the demand stage, or whether it is only because the activities in the design stage do not meet or meet the settings or requirements of the demand stage, that is, the requirements are not fully or correctly designed, so as to locate whether the defect is fundamentally introduced in the demand or design stage; if it is obtained from the coding and post-coding stages, similarly, analyze and trace upward in turn to see whether it can be traced back to the requirements, design or coding as errors in the implementation, so as to locate whether the defect is fundamentally introduced in the requirements, design or coding stages.

[0067] The defect data is a tuple, as shown below:

[0068]

[0069] Where: Dt represents the defect dataset; id represents the unique number of the defect; csc i Indicates the software to which the defect belongs; sys i Indicates the system to which the defect belongs; md i Indicates the equipment model to which the defect belongs; ba iIndicates the batch of software products where the defect is located; cd indicates the date when the defect was collected; sc i Indicates the defect source unit; des indicates the overall description of the defect given in a semi-formal language; fd i Indicates the software development phase where defects are discovered;br i Indicates the software development phase that introduces defects; i Indicates the factors that introduce defects; tp i Indicates the type determined according to the characteristics of aviation equipment software; gd i Indicates the degree of defect; st i Indicates the defect control status derived from the defect life state; mt i Indicates the defect type involved in the defect; mc i It indicates the work product involved in the defect; ms indicates the specific content description of the defect; f indicates the software failure caused by the defect; pa indicates the impact caused by the failure.

[0070] According to the objective facts shown in the defect record, the defect is directly determined to belong to the software csc = temperature control software, belonging to the system: ground system - ground maintenance system sys i =0200, product model: airborne JX aircraft mdi=0006, product batch: 01 batch bai=01, collection date: 2018.4.25cd=20180425, source unit: Aviation Industry-East China Optoelectronics sci=0022.

[0071] S2: Based on the basic information of the software defect, handle the defect problem and make a detailed description of the modification content.

[0072] S21: Determine the type of software based on the characteristics of aviation equipment according to the problem description and cause of the problem in the basic defect information. i ; Map the defect to the defect type feature description table to determine the type determined for the characteristics of aviation equipment software tp i ; The temperature sensor belongs to the analog quantity acquisition of the input type. According to the problem description and the cause of the problem, the sampling channel of the screen B temperature sensor is set to the same as the screen A temperature sensor to facilitate development and debugging. As a result, the screen B temperature sensor uses the sampling value of the screen A temperature sensor and the fault judgment function of A when judging the fault. It is known that this defect is caused by the lack of screen B temperature sensor fault detection in the software. The defect type is: no extreme value detection and fault handling strategy, tp i =00010400.

[0073] S22: According to the problem description and cause, combined with the external environment of software operation, determine the software failure performance f caused by the defect being triggered and the impact pa caused by the failure; combined with the actual software external input and output, actual operation, analyze the defect connotation, related data flow, related functions and the final abnormal output, that is, the analysis model, and determine the failure performance f associated with the defect; combined with the external environment, associations and device functions of the software operation, determine the impact pa caused by the failure; software fault detection is disordered, prone to false alarms / false alarms or fault failures, and at the same time can cause the display screen to fail to heat up, causing the display screen to fail, or high temperature without brightness limit causing the screen to heat up and cause the screen to overheat and burn.

[0074] S23: Determine the defect control status st obtained based on the defect life state i And give the work product mc involved in the defect i 、Defect type mt i and the specific content description of the defect to determine whether ms can be collected; since the collection timing of defects and the management and control of defects are throughout the entire equipment software development stage, if the current defect has been controlled and handled before collection and the handling situation has been filled in, then for the defect control status st derived from the defect life state i The characteristic is to close the i = 00, and further determine the value according to the stage at which the defect is closed. At the same time, the work product mc i and the defect type mt involved in the defect i , the specific content description of the defect ms is in the state of being able to be collected, and S24 is executed; at this time, if the current defect has not been controlled before collection or there is no clear control measure, the defect state st i The feature is opened. Since the defect is in an unhandled state, the work product mc i 、Defect type mt i The characteristics of the specific content description ms of the defect cannot be determined at this time and are in a state of being unable to be collected. S25 is skipped and the execution continues backward, and S24 can only be executed after the three can be collected.

[0075] S24: If mc i 、mt i If both ms and mc can be collected, the work product mc involved in the defect is determined in turn according to the problem type and disposal measures in the basic information of the defect. i and the defect type mt involved in the defect i;Program code mci=01000(B)=08(D);Since the modification content involves the selection of input acquisition channels and the calling of sub-functions in the cyclic self-test, the modification type is: input and processing logic mti=00001||00100=00101(B)=03(D).

[0076] S25: Based on the work product mc involved in the defect i Combined with the disposal measures in the basic defect information, determine the specific content description of the defect ms; the work product mc involved in the defect i It is strongly associated with the specific content description of the defect. The semi-automatic language is used to describe the modified content in detail, which is divided into the first type of description and the second type of description, as follows:

[0077] The first type of description is: if the modified content is a different combination of requirement specifications, design specifications, ICD or other documents, that is, if mc i &(10111)! = 0; mc i If any bit in bit2 to bit0 and bit4 is 1, the description is as follows: delete, add and modify in chapter X, where X is the corresponding document; modify L393 in the ad_convert() function of the WDM6505A_OGB615_V200.c file to temp = sample_array(PING_B_TEMP_SENSOR,AD1DAT1).

[0078] The second description method: Delete, add and modify the functions Lm~Ln in the Xc file Y. Modify the code at L395 in the ad_convert() function in the WDM6505A_OGB615_V200.c file to get_pb_temp(temp).

[0079] S3: Based on the cause of the problem in the basic information of the defect, a defect ID is formed and a defect data set is constructed.

[0080] S31: Determine the degree of defect gd based on the level of the problem, the importance of the software, and the defect levels of each level, combined with the software failure manifestation f caused by the defect, the impact pa caused by the failure, or the associated system hazard. i ; The problem level and the defect level need to satisfy a one-to-one correspondence. The problem level critical corresponds to the defect level critical, the problem level important corresponds to the defect level important, the problem level corresponds to the defect level, the problem level suggestions for improvement, minor and the corresponding defect level minor, the software failure manifestation f caused by the defect being stimulated, the impact pa caused by the failure, and the associated system hazards are determined.

[0081] S32: Software development based on the introduction of defects i , factors that introduce defects i and the type tp determined according to the characteristics of aviation equipment software i The overall description of the defect des given in a semi-formal language is as follows:

[0082] des = {br i ,res i ,tp i};

[0083] S33: According to the date cd of defect collection and the defect source unit sc i Automatically generate defect ID; defect ID consists of cd, sc i The eigenvalues ​​of are formed directly with the natural numbering as follows:

[0084] id=('Dt'<<15)|(cd<<7)|(sc i <<3)|N;

[0085] Where: N represents a set of natural numbers.

[0086] Collection date: 2018.4.25cd=20180425, source unit: Aviation Industry-Huadong Optoelectronics sci=0022, and the current defect belongs to the first defect data collected, so the defect ID id=DT201804250022001.

[0087] S34: Each defect data formed in this numbering method can ensure uniqueness; according to the above steps, the basic information of the defect is collected to form unified, standardized and concise defect data, forming a complete defect data set Dt.

[0088] S4: Obtain security analysis data of defects based on TextRank keyword extraction technology.

[0089] Get the defect dataset in S3 and use the TextRank keyword extraction technology to extract the key defects in the defect dataset, as shown below:

[0090]

[0091] Where: WS(V i ) represents the weight of defect i; V i represents the i-th defect; d represents the damping coefficient; V j Indicates the jth defect; In(V i ) represents the data set of the i-th defect; W ji Indicates the similarity between defect j and defect i; V kIndicates the kth defect; Out(V j ) represents the dataset of the j-th defect; W jk Indicates the similarity between defect j and defect k; WS(V j ) represents the weight of defect j.

[0092] The security analysis data of the defects according to the critical defects is as follows:

[0093] R mnpq ={rtp m ,rc n ,rd p ,rs q};

[0094] Where: Rl mnpq Security analysis data indicating defects; rtp m The first-level feature map representing the defect type; rc n The second-level feature map representing the defect type; rd p The third-level feature map representing the defect type; rs q Fourth-level feature map representing defect types.

[0095] Establish a mapping from defect data set Dt to analysis data Rl. The specific steps are as follows:

[0096] S41: Establish a mapping from the defect data set Dt to the analysis data Rl classification: transform the defect type attribute tp of Dt i The first three levels of features are mapped to rtp m rc n ,rd p , thereby determining the three-level classification of the analysis data corresponding to the defect data; the classification of the safety analysis data corresponding to the defect data obtained from the defect type of the DT201804250022001 defect data formed in S1 is input class-analog quantity-fault detection and processing strategy.

[0097] S42: Establish a mapping from the defect data set Dt to the analysis data description: Map the defect type attribute tp of Dt to i The fourth-level feature map is a detailed description of the analysis data rs q , the mapping rule is to carry out fault flow and data flow analysis according to the software failure performance f caused by the defect being triggered, and determine the factors that should be fully considered or protected during the analysis, as each analysis data rs q , usually a one-to-many mapping relationship.

[0098] S43: Traverse Rl mnpqWhether the criterion already exists in the analysis data, if so, it is discarded; otherwise, it is added as a new criterion under the third-level classification of the analysis data.

[0099] S44: According to the above steps, the associated analysis data is extracted from the defect data that has been collected, and the safety analysis data set R1 is continuously enriched and improved.

[0100] Finally, the data extraction of aviation equipment software safety analysis can be realized. Figure 2 The figure shows a detailed flow chart of the method for extracting software safety criteria according to an embodiment of the present invention. Table 2 shows the extraction and analysis results of aviation equipment software safety criteria based on defect extraction technology. The attached table proves that the method has a good application effect and performs well in practical applications.

[0101] Table 2 Safety analysis data based on temperature control software defect data

[0102]

[0103] In summary, the prediction results of the method of extracting defect information from aviation equipment software safety analysis data in this case have proven to be very effective.

[0104] (1) The embodiments of the present invention can fully mine and utilize valuable information in defect data, summarize and extract the implicit repetitive and regular information therein, form analysis data, and clearly give the direction of software security analysis, and provide analysis scope, ideas and prior knowledge guidance for subsequent security analysis work. The simulation and security analysis of temperature control software prove that the application effect of this method is good.

[0105] (2) The embodiments of the present invention can conduct security analysis on software requirements in a more targeted manner, identify failure modes in various software requirements more fully and accurately, make the analysis scope more precise and specific, and make the analysis more efficient, thereby significantly improving the overall equipment development efficiency and effectively ensuring that the software maintains safety during use.

[0106] (3) The embodiment of the present invention uses the TextRank keyword extraction technology to realize the extraction, analysis and processing of software defect data. The algorithm principle is simple and the deployment is simple, the application effect is good, and it can make fuller use of the relationship between text elements to meet actual application needs.

[0107] The embodiments described above are only descriptions of the preferred implementation modes of the present invention, and are not intended to limit the scope of the present invention. Without departing from the design spirit of the present invention, various modifications and improvements made to the technical solutions of the present invention by ordinary technicians in this field should all fall within the protection scope determined by the claims of the present invention.

Claims

1. A method for extracting aviation equipment software safety analysis data based on defect information, characterized in that: It includes the following steps: Step 1: Obtain defect data and determine basic defect information; According to the information of the aviation equipment software where the defect is located, obtain the defect data and determine the software development link where the defect is found. i and the software development process that introduces defects i :The defect data is a multi-tuple, as shown below: Where: Dt represents the defect dataset; id represents the unique number of the defect; csc i Indicates the software to which the defect belongs; sys i Indicates the system to which the defect belongs; md i Indicates the equipment model to which the defect belongs; ba i Indicates the batch of software products where the defect is located; cd indicates the date when the defect was collected; sc i Indicates the defect source unit; des indicates the overall description of the defect given in a semi-formal language; fd i Indicates the software development phase where defects are discovered;br i Indicates the software development phase that introduces defects; i Indicates the factors that introduce defects; tp i Indicates the type determined according to the characteristics of aviation equipment software; gd i Indicates the degree of defect; st i Indicates the defect control status derived from the defect life state; mt i Indicates the defect type involved in the defect; mc i Indicates the work product involved in the defect; ms indicates the specific content description of the defect; f indicates the software failure caused by the defect; pa indicates the impact caused by the failure; Step 2: According to the basic information of the software defect, handle the defect problem and make a detailed description of the modification content; Step 3: According to the cause of the problem in the basic information of the defect, a defect ID is formed and a defect data set is constructed; Step 31: Determine the defect severity level gd based on the level of the problem, the importance of the software, and the defect levels of each level, combined with the software failure performance f caused by the defect being triggered, the impact pa caused by the failure, or the associated system hazard. i ; Step 32: According to the software development link that introduced the defect i , factors that introduce defects i and the type tp determined according to the characteristics of aviation equipment software i The overall description of the defect des given in a semi-formal language is as follows: of={br i ,res i ,tp i }; Step 33: According to the date of defect collection cd and defect source unit sc i Automatically generate a defect ID; the defect ID consists of cd, sc i The eigenvalues ​​of are formed with natural numbers as follows: id=(‘Dt’<<15)|(cd<<7)|(sc i <<3)|N; Where: N represents the set of natural numbers; Step 34: Each defect data formed in this numbering method can ensure uniqueness; according to the above steps, the basic information of the defect is collected to form unified, standardized and concise defect data, forming a complete defect data set Dt; Step 4: Obtain security analysis data of defects based on TextRank keyword extraction technology; Get the defect data set in step 3 and use the TextRank keyword extraction technology to extract the key defects in the defect data set, as shown below: Where: WS(V i ) represents the weight of defect i; V i represents the i-th defect; d represents the damping coefficient; V j Indicates the jth defect; In(V i ) represents the data set of the i-th defect; W ji Indicates the similarity between defect j and defect i; V k Indicates the kth defect; Out(V j ) represents the data set of the j-th defect; W jk Indicates the similarity between defect j and defect k; WS(V j ) represents the weight of defect j; The security analysis data of the defects according to the critical defects is as follows: Rl mnpq ={rtp m ,rc n ,rd p ,rs q }; Where: Rl mnpq Security analysis data indicating defects; rtp m The first-level feature map representing the defect type; rc n A second-level feature map representing the defect type; rd p A third-level feature map representing the defect type; rs q The fourth level feature map representing the defect type; Establish a mapping from defect data set Dt to analysis data set Rl to realize the extraction of aviation equipment software safety analysis data.

2. The method for extracting aviation equipment software safety analysis data based on defect information according to claim 1 is characterized in that: The software development link fd in step 1 to find defects i and the software development process that introduces defects i The method for obtaining the value is as follows: The software development link where the defect was found i The values ​​of are: demand analysis and review, design analysis and review, coding self-test and review, testing and review, joint commissioning and review or maintenance; the specific values ​​are determined according to the activities when the defect is discovered, including; The software development link that introduces defects i The value of is: requirements, design or coding stage. It is necessary to fully analyze and trace the specific manifestation of the defect when it is discovered. If the defect is discovered in the requirements analysis stage, then what is discovered at this time is a requirement defect, and it can be directly located that the defect was introduced in the requirements stage. If the defect is discovered in the design phase, it is necessary to analyze whether the defect can be traced back to the inadequacy of the activities in the demand phase, or whether it is simply because the activities in the design phase do not meet or meet the settings or requirements of the demand phase, that is, the requirements are not fully or correctly designed, so as to determine whether the defect is fundamentally introduced in the demand or design phase; if it is obtained from the coding and post-coding stages, similarly, analyze and trace upward in turn to see whether it can be traced back to errors in the demand, design or coding implementation, so as to determine whether the defect is fundamentally introduced in the demand, design or coding phase.

3. The method for extracting aviation equipment software safety analysis data based on defect information according to claim 1 is characterized in that: The unique number of the defect in step 1 is specifically: The unique ID of the defect is composed as follows: id={cd,sc i ,‘No’}; Where: No represents the status of the unique number of the defect.

4. The method for extracting aviation equipment software safety analysis data based on defect information according to claim 1 is characterized in that: In step 2, based on the basic information of the software defect, the defect problem is processed and a detailed description of the modification content is made, specifically: Step 21: According to the problem description and cause in the basic defect information, determine the type tp determined for the characteristics of aviation equipment software i ; Map the defect to the defect type feature description table to determine the type determined for the characteristics of aviation equipment software tp i ; Step 22: According to the problem description and the cause of the problem, combined with the external environment of the software operation, determine the software failure performance f caused by the defect being triggered and the impact pa caused by the failure; combined with the actual software external input and output and actual operation, analyze the defect connotation, related data flow, related functions and the abnormal output caused in the end, that is, the analysis model, and determine the failure performance f associated with the defect; combined with the external environment of the software operation, associations and the functions of the equipment where it is located, determine the impact pa caused by the failure; Step 23: Determine the defect control status based on the defect life cycle status i And give the work product mc involved in the defect i 、Defect type mt i and the specific content description of the defect to determine whether ms can be collected; since the collection timing of defects and the management and control of defects are throughout the entire equipment software development stage, if the current defect has been controlled and handled before collection and the handling situation has been filled in, then for the defect control status st derived from the defect life state i The characteristic is to close the i = 00, and further determine the value according to the stage at which the defect is closed. At the same time, the work product mc i and the defect type mt involved in the defect i , the specific content description of the defect ms is in the state of being able to be collected, and step 24 is executed; at this time, if the current defect has not been controlled before collection or there is no clear control measure, then the defect state st i The feature is given open. Since the defect is in an unhandled state, the work product mc i 、Defect type mt i The characteristics of the specific content description ms of the defect cannot be determined at this time, and it is in a state of being unable to be collected. Step 25 is skipped and the execution continues, and step 24 can be executed only after the three can be collected; Step 24: If mc i 、mt i If both ms and mc can be collected, the work product mc involved in the defect is determined in turn according to the problem type and disposal measures in the basic information of the defect. i and the defect type mt involved in the defect i ; Step 25: Based on the work product mc involved in the defect i Combined with the disposal measures in the basic information of the defect, determine the specific content description of the defect ms; the work product mc involved in the defect i It is strongly associated with the specific content description of the defect. The semi-automatic language is used to describe the modified content in detail, which is divided into the first type of description and the second type of description, as follows: The first type of description is: if the modified content is a combination of requirement specifications, design specifications, ICD or other documents, that is, if mc i &(10111)! = 0; mc i If any bit in bit2 to bit0 and bit4 is 1, the description is: delete, add and modify in chapter X, where X is the corresponding document; The second type of description method: deleting, adding and modifying the Xc file Y functions Lm~Ln.

5. The method for extracting aviation equipment software safety analysis data based on defect information according to claim 1 is characterized in that: In step 31, the problem level and the defect level need to satisfy a one-to-one correspondence. The problem level critical corresponds to the defect level critical, the problem level important corresponds to the defect level important, the problem level corresponds to the defect level, the problem level recommended improvement, minor and the corresponding defect level minor, the software fault failure manifestation f caused by the defect being stimulated, the impact pa caused by the failure, and the associated system hazards are determined.

6. The method for extracting aviation equipment software safety analysis data based on defect information according to claim 1 is characterized in that: In step 4, a mapping from the defect data set Dt to the analysis data Rl is established. The specific steps are as follows: Step 41: Establish a mapping of the defect data set Dt to the analysis data Rl classification: transform the defect type attribute tp of Dt into i The first three levels of features are mapped to rtp m rc n ,rd p , thereby determining the three-level classification of the analysis data corresponding to the defect data; Step 42: Establish a mapping from the defect data set Dt to the analysis data description: Map the defect type attribute tp of Dt to i The fourth-level feature map is a detailed description of the analysis data rs q , the mapping rule is to carry out fault flow and data flow analysis according to the software failure performance f caused by the defect being triggered, and determine the factors that should be fully considered or protected during the analysis, as each analysis data rs q , usually a one-to-many mapping relationship; Step 43: Check if Rl already exists in Rl mnpq , if it exists, it is discarded; otherwise, it is added as the safety analysis data of the new defects under the third-level classification of the analysis data; Step 44: According to the above steps, the associated analysis data is extracted from the defect data that has been collected, and the safety analysis data set R1 is continuously enriched and improved.

Images