WO2017217701A1 - Method and device for analyzing safety of software for electric device - Google Patents

Abstract

Provided is a method by which a computer analyzes the safety of software for an electric device. The method for analyzing the safety of software for an electric device can comprise the steps of: receiving software for an electric device; dividing the software for an electric device into one or more code modules; measuring danger metric data values, corresponding to pieces of danger metric data, for each code module by using an analysis machine, wherein the analysis machine is a learning machine, which has been pre-taught and trained by a plurality of danger metric data sets related to a vehicle function safety, and each danger metric data set includes a plurality of danger metric data; respectively determining, for each code module, values indicating whether there is danger, by using the analysis machine, on the basis of the danger metric data values; determining, for each code module, values indicating whether there is danger, by using the analysis machine, on the basis of one or more of the measured danger metric data values; and drafting a report on the safety of software for an electric device by using the value, indicating whether there is danger, determined for each code module.

Description

Electronic Software Safety Analysis Method and Apparatus

The present invention relates to a vehicle safety software safety analysis method and apparatus, and more particularly, to a vehicle electronics software safety analysis method and apparatus.

Recently, with the diversification and advancement of vehicle electronics, the automotive electronics market is also rapidly growing. In addition, efforts are being made to improve the manufacturing efficiency of vehicle electronics software and to prevent defects. For example, many automotive companies are developing software for electronics, respectively, based on ISO 26262 automotive electrical and electronic systems safety certification standards and AUTOSAR development platforms.

On the other hand, electronic software is capable of causing irreparable damage in the event of an error. In addition, various accidents and events caused by errors in the electronic software have been steadily occurring, and as a result, interest in safety of the electronic software is increasing day by day. In addition, due to the advancement and diversification of electronic software, the damage caused by defects or failures of the software is becoming more serious. Accidents caused by software defects can damage the safety of customers and the image of the automobile company. have. Therefore, it is important to be able to predict the possibility of defects in electronic software early in the life of the software and to fix them quickly, and for software written based on standards, the prediction and verification of such defect potential are very important issues.

On the other hand, the work of analyzing and predicting defects of various software including vehicle software has been conventionally performed manually by human hands. For example, in the field of electronics, software specialists have mostly been manually checking for compliance with coding rules of the Motors Industry Software Reliability Association (MISRA) designation for each software module.

However, such a manual analysis method has a problem that the analysis accuracy is low and the stability of the analysis is difficult to expect in the current situation where the complexity of the code structure of the electronic software is increasing day by day. In addition, it is difficult to identify which part of a large-scale electronic software is urgently needed for defect repair, and there is a difficulty in efficiently allocating limited resources (e.g., distribution of development / maintenance personnel) in software development / maintenance. come.

Therefore, there is a need for an accurate and reliable method of safety analysis of automated electronic software. In addition, it is necessary to provide the analysis result in a manner that the user can intuitively recognize and use it immediately so that the user can refer to it in order to prioritize tasks for defect repair of the electronic software in the future.

According to one aspect of the present invention, there is provided a method for safety analysis of electronic software, which is performed by a computer. Safety analysis method of the electronic software in accordance with the present invention, receiving the electronic software; Partitioning the electronic software into one or more code modules; The analysis machine, which is a learning machine pre-learned and trained by a plurality of risk metric data sets, relating to vehicle functional safety, each risk metric data set comprising a plurality of risk metric data, each For the code module of, measuring risk metric data values corresponding to the risk metric data; For each code module, using the analysis machine, based on the risk metric data values, respectively, determining a value indicative of a risk; Using an analysis machine, for each code module, determining, based on one or more of the measured risk metric data values, a value indicating whether a risk is present; And generating a report on the safety of the electronic software, using a value indicating whether the risk is determined for each code module.

According to one embodiment of the invention, the risk metric data values include a risk level value for a code module, wherein the risk level value comprises one or more of a severity level value, a probability of occurrence value, and an implementation difficulty level value of the code module. The risk level value is defined as one of i risk level values, the implementation difficulty level value is one of j implementation difficulty level values, and i and j may be integers of two or more.

According to one embodiment of the present invention, the risk metric data values are, for code modules, the total number of code lines (loc), McCabe cyclic complexity (v (g)), McCabe required complexity (ev (g)), McCabe design. Complexity (iv (g)), total number of Halstead operators and operands (n), Halstead program volume (v), Halstead program length (l), Halstead program difficulty (d), Halstead Intelligent content (i), Halstead programming effort ( e), Halstead error estimation (b), Halstead implementation time estimation (t), Halstead line count (lOCode), Halstead comment lines (lOComment), Halstead blank lines (lOblank), Number of lines with both code and comments ( IOCodeANDComment), the number of unique operators (uniq_Op), the number of unique operands (uniq_Opnd), the total operator (total_Cp), the total operands (tatal_Opand), and the graph flow number (branchCount).

According to one embodiment of the invention, the step of creating a report on the safety of the electronic software, using a value indicating whether the risk determined for each code module. Calculating a local risk index of the code module.

According to an embodiment of the present invention,

The local risk index for code modules is

Local risk index = (code module implementation difficulty level value + code module risk level value) / (i + j)

Can be determined by.

According to one embodiment of the invention, the step of generating a report on the safety of the electronic software, using a value indicating whether the risk determined for the code module. Calculating the total risk index of the electronic software.

According to one embodiment of the invention, the step of dividing the electronic software into one or more code modules comprises dividing the electronic software into n code modules, wherein the total risk index of the electronic software is

Total risk index =

Local Risk Index _i * 100

Can be determined by.

According to one embodiment of the invention, the step of preparing a report on the safety of the electronic software. One or more code modules may include generating a report using information about the location of the hazard code, how to supplement the hazard code, and the expected input effort.

According to another aspect of the present invention, there is provided a computer device operable to perform any one of the above-described safety analysis methods of electronic software.

According to still another aspect of the present invention, a computer-readable storage medium having one or more instructions stored thereon, wherein the one or more instructions, when executed by a computer, cause the computer to perform any of the methods of safety analysis of the above-mentioned electronic software. A computer readable storage medium is provided for executing the program.

According to the present invention, based on machine learning or deep learning technology, an accurate and safe method for safety analysis of electronic software can be provided. According to the present invention, the results of the safety analysis of the electronic software can be intuitively recognized by the user and can be immediately utilized for future reference in determining priorities for defect repair of the electronic software. , Can be provided.

1 is a flow block diagram schematically illustrating a process of generating and utilizing an analysis machine for automatic analysis of reliability and safety of electronic software according to an embodiment of the present invention.

2 illustrates an exemplary set of risk data metrics to be used as input values in the creation and training of an analysis machine, in accordance with an embodiment of the present invention.

3 is a table showing an example of S _n data that may be used in an exemplary process of reducing metric data to sensitive metric data to be used for reliability or safety analysis of an analysis machine.

4 is a functional block diagram of a software reliability and safety analysis machine 400, in accordance with an embodiment of the present invention.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the following, when it is determined that there is a risk of unnecessarily obscuring the gist of the present invention, a detailed description of the known functions and configurations will be omitted. In addition, it should be understood that the following description only relates to one embodiment of the present invention, but the present invention is not limited thereto.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the present invention. For example, a component expressed in the singular may not be used in the singular unless the context clearly indicates the singular. It should be understood as a concept involving components. In addition, in the specification of the present invention, terms such as 'comprise' or 'have' are merely intended to designate that the features, numbers, steps, operations, components, parts, or combinations thereof described in the specification exist. The use of the term is not intended to exclude the presence or addition of one or more other features or numbers, steps, actions, components, parts or combinations thereof.

In the embodiments described herein, 'block' or 'unit' means a functional part that performs at least one function or operation, and may be implemented in hardware or software or in a combination of hardware and software. The plurality of blocks or portions may be integrated into at least one software module and implemented as at least one processor, except for blocks or portions that need to be implemented in specific hardware.

In addition, all terms used herein, including technical or scientific terms, unless otherwise defined, have the same meaning as commonly understood by one of ordinary skill in the art. It is to be understood that generally defined terms used should be construed as having a meaning consistent with the contextual meaning of the related art, and shall not be construed as being excessively limited or extended unless expressly defined otherwise in the specification of the present invention. You should know

Hereinafter, with reference to the accompanying drawings, it will be described in detail an embodiment of the present invention.

1 is a flow block diagram schematically illustrating a process of generating and utilizing an analysis machine for automatic analysis of reliability and safety of electronic software according to an embodiment of the present invention.

As shown, in block 102, as a basic procedure for the creation of a battlefield software analysis machine, elements related to vehicle functional safety, such as functional safety elements defined in ISO 26262 or functional safety elements defined in AUTOSAR Various vehicle functional safety factors are collected, such that risk data metrics of the functional safety factor may be selected to be used as input in the generation and training of the analysis machine. The selection of risk data metrics related to functional safety can be made in a variety of ways, for example, by the use of a domain expert or by an interview.

An exemplary set of risk data metrics to be used as input values in the creation and training of an analysis machine, according to one embodiment of the invention, is shown in FIG. 2. As shown in FIG. 2, the input values for generation and training of the analysis machine may include 22 risk data metrics relating to the code module.

Specifically, as shown, the risk data metrics to be used in the creation and training of the analysis machine include, for example, the total number of code lines (loc), McCabe cyclic complexity (v (g)), McCabe required complexity (ev (g)). , McCabe design complexity (iv (g)), total number of Halstead operators and operands (n), Halstead program volume (v), Halstead program length (l), Halstead program difficulty (d), Halstead Intelligent content (i), Halstead With programming effort (e), Halstead error estimation (b), Halstead implementation time estimation (t), Halstead line count (lOCode), Halstead comment lines (lOComment), Halstead blank lines (lOblank), code and comments Number of lines (IOCodeANDComment), number of unique operators (uniq_Op), number of unique operands (uniq_Opnd), total operators (total_Cp), total operands (tatal_Opand), graph flow count (branchCount), and code module risk level Risk data metric may be included. According to an embodiment of the present invention, a risk level is a risk level defined in accordance with a given specification of each code module, for example, a severity level indicating how serious a failure of each code module causes damage, and a failure of such a code module. It may be a value defined in advance by the probability of occurrence of the damage caused by the damage, the level of difficulty in implementing the code module. If the damage caused by the failure of the corresponding code module causes a serious life risk, the code module may have a higher severity level than the code module which causes only minor damage or minor injury even if the error occurs. In addition, even in a code module having a high severity level, if the probability of occurrence of such a code module is very low, the overall risk level may be a low value. The table below is only illustrative of how to classify risk levels, and the invention is not so limited. Those skilled in the art will be able to come up with ways to classify risk levels in various forms, taking into account the characteristics of each code module.

		D1	D2	D3
S1	E1	0	0	0
	E2	0	0	0
	E3	0	0	One
	E4	0	One	2
S2	E1	0	0	0
	E2	0	0	One
	E3	0	One	2
	E4	One	2	3
S3	E1	0	0	One
	E2	0	One	2
	E3	One	2	3
	E4	2	3	4
<Severity level> S1 = minor; S2 = medium phase; S3 = serious risk of life <probability of occurrence> E1 = very low probability; E2 = low probability; E3 = medium probability; E4 = high probability <implementation difficulty> D1 = easy; D2 = medium; D3 = Difficult

Those skilled in the art will be familiar with the meaning of each of the other risk data metrics shown in FIG. 2 in addition to the risk levels described above, and a detailed description thereof will be omitted herein. In addition, those skilled in the art will appreciate that the data metrics shown in FIG. 2 are only one embodiment of the invention, and the invention is not so limited.

Returning back to FIG. 1, at block 104, specific learning and training data may be prepared for use in generating an analysis machine based on the definition of each risk data metric defined at block 102. According to one embodiment of the present invention, for example, a test data set provided by NASA may be used, but the present invention is not limited thereto.

At block 106, an analysis machine (deep learning machine) for automated analysis of reliability and safety of the electronics for the electronics is initially designed, and the analysis machine may be initially trained using the training data prepared at block 104. According to an embodiment of the present invention, an analysis machine may be designed according to an artificial neural network (ANN) or support vector machine (SVM) technique, but the present invention is not limited thereto. Those skilled in the art will appreciate that analytical machines can be implemented by a variety of other deep learning schemes.

In block 108, the initially trained analysis machine is tested using the test data prepared in block 104 and error rate analysis of the analysis machine according to the test result is performed, and the error rate analysis result is fed back to block 106. Can be entered. As such, the test results of the analysis machine at block 108 may be fed back repeatedly to the machine design and learning phase of block 106 so that the analysis machine may be modified accordingly. As the process of iterative machine modification in accordance with these blocks 106 and 108 is performed, the creation of the code safety analysis machine can be completed.

On the other hand, with respect to the analysis machine for automatic analysis of reliability and safety of the electronic software according to an embodiment of the present invention, if the number of risk data metrics of the code module to be used in software analysis by the analysis machine is too large Increasing the dimension can make it difficult to accurately and efficiently model the analysis results. Conversely, it may be difficult to find the correct association between the input and the analysis result if the number of risk data metrics of the code module to be used is too small. Therefore, it may be more desirable to limit the risk data metrics of each code module to be used for analysis of the analysis machine to important and sensitive data metrics that are closely related to the reliability and safety of the code module. In other words, it is possible to find out which of the risk metric data that the analysis machine can use for analysis greatly affects the analysis result even if the slight change in the value is made, and limit such sensitive data to be used in the analysis machine. .

For example, if the total number of metric data used for the initial generation of the analysis machine is d, and there are i training data sets each having d input data sets, then each nth of the samples in all i sets (1≤n ≤ d) The sensitivity of the input value (danger metric data value) of the position to the analysis result can be determined in the following manner.

S _n =

DS _k

DS _k = O (I _k ) -O (I _k + Δ _kn )

I _k : set of kth input samples

O (I _k ): Trained machine output value of the kth input sample set

I _k + Δ _kn : From the kth input sample set, the nth value of the kth input sample set plus the small constant value Δ

O (I _k + Δ _kn ): Machine output value trained on the kth input sample set, the nth value of the kth input sample set plus the small constant Δ

According to the above equation, of each risk data metric belonging to the input sample set, the value of S _n is greater than or equal to a predetermined value, that is, the sensitive risk data metric that greatly affects the output value of the analysis machine even if the given value changes slightly. Can be found.

Returning to FIG. 1 again, at block 110, a safety analysis of the electronic software using the analysis machine is performed. Although not specifically illustrated, according to an embodiment of the present invention, the safety analysis result of the software at block 108 may be fed back to block 106 to update the analysis machine. A detailed safety analysis process of the electronic software will be described in detail later with reference to FIG. 4.

At block 112, the results of the analysis performed by the analysis machine at block 110 may be reported in a manner that is useful and intuitive to the user. For example, the reporting of the analysis result may include a diagram of the analysis result, an indication of the achievement goal and the current level against it, a future action plan according to the achievement goal, and the like.

FIG. 3 is a table showing an example of S _n data that may be used in an exemplary process of reducing metric data to sensitive metric data to be used for reliability or safety analysis of an analysis machine, as described above. In the embodiment of the present invention according to FIG. 3, the number of each risk data metric of the input data used to generate the analysis machine is 21 (the same as excluding the risk level among the risk data metrics of FIG. 2), and a constant value. It is assumed that Δ is 0.1, and only data whose value of S _n is 0.1 or more is determined as sensitive data. In such a case, the data selected to be included in the input data metric set again based on the table shown may be reduced to 14 (ie loc, branchCount, iv (g), v, lOCodeAndComment, lOCode, uniq_Opnd, d, lOComment) , e, v (g), n, total_Opnd, uniq_Op). This reduction can limit input to values that are highly correlated with the analysis results, allowing for more efficient and accurate analysis.

4 is a functional block diagram of a software reliability and safety analysis machine 400, in accordance with an embodiment of the present invention. As shown, the analysis machine 400 includes an input unit 402, a risk data metric measurement unit 404, a risk analysis unit 406, and a report generator 408.

According to an embodiment of the present invention, the input unit 402 may receive a code input of the created electrical equipment software. The input software may be ready-made or electronic software under development. Software may include one or more code modules. The input unit 402 may also divide the input software into one or more code modules, such as one or more functions.

According to one embodiment of the invention, the risk data metric measurement unit 404, for each code module (e.g., each function unit) of the software input and divided by the input unit 402, block 102 of FIG. The value of each of the risk data metrics of the functional safety factor selected and used in the analysis machine creation (or the value of such limited sensitive metric data if the risk data metrics to be used for analysis are limited to sensitive data) can be measured. For example, in the risk data metric measuring unit 404, for each code module of the input software, the total number of code lines loc, McCabe cyclic complexity v (g), McCabe required complexity ev (g), McCabe design complexity (iv (g)), total number of Halstead operators and operands (n), Halstead program volume (v), Halstead program length (l), Halstead program difficulty (d), Halstead Intelligent content (i), Halstead programming Effort (e), Halstead error estimation (b), Halstead implementation time estimation (t), Halstead line count (lOCode), Halstead comment lines (lOComment), Halstead blank lines (lOblank), lines with both code and comments Risks such as number (IOCodeANDComment), number of unique operators (uniq_Op), number of unique operands (uniq_Opnd), total operators (total_Cp), total operands (tatal_Opand), graph flow count (branchCount), and risk level One or more of the data metric values may be measured automatically.

According to an embodiment of the present invention, the risk analyzer 406 uses the risk data metrics of each code module measured by the risk data metric measurer 404, including the risk level value measured for each code module. Each code module is analyzed for risks. The analyzed result may be output as a value of True or False indicating whether the corresponding module is dangerous for each code module.

According to the exemplary embodiment of the present invention, the report generator 408 may automatically generate a report on whether the input software is dangerous. According to one embodiment of the present invention, the report generator 408, along with the risk analysis results (ie True or False value for each code module) of each code module obtained from the risk analysis unit 406, The risk data metric measuring unit 404 may generate a report using a risk level value of each code module of the input software and an implementation difficulty value used to measure the risk level value. According to an embodiment of the present invention, in the report generator 408, the risk index (local risk index) of each code module of the software and the risk index (total risk index) of the entire software are calculated by each predetermined method, Reports on the risk of input software can be generated, including calculated local risk scores and total risk scores.

For example, each of the local risk index and the total risk index of each code module can be calculated by the following equation.

Local Risk Index = (Code Module Implementation Difficulty Value + Code Module Risk Level Value) / (Total Implementation Difficulty Level + Total Risk Level)

For example, as in the embodiment described above in connection with Table 1, in the case where the total implementation difficulty level is three, a particular code module is the second stage, that is, the second most difficult stage (eg D2), and the overall risk level. In the case of these five cases, if the particular code module is in the third risk stage (eg, 2), the local risk index for that particular code module may be (2 + 3) / (3 + 5) = 0.625.

In addition, the total risk index for the entire software code can be calculated by averaging each local risk index of each code module belonging to a software code.

Total risk index =

Local Risk Index _i * 100

For example, if the input software contains three code modules, and each code module has a local risk index of 0.73, 0, and 1, the total risk index is 1/3 (0.73 + 0 + 1) * 100 = 57.7%. Can be

It should be noted that the method for calculating the risk index described above is only one embodiment of the present invention, and the present invention is not limited thereto. The local risk index of each code module and the total risk index of the entire software calculated in this way may be used by the report generator 408 to generate a report on whether or not the software is dangerous as described above. According to an embodiment of the present invention, the report generation includes the risk code, together with the aforementioned information, such as the result of the risk analysis of each code module, the local risk index of each code module, and / or the total risk index of the entire software. Information may be further included on location indications, complementary measures, and anticipated input efforts.

As will be appreciated by those skilled in the art, the present invention is not limited to the examples described herein but may be variously modified, reconfigured and replaced without departing from the scope of the present invention. For example, the various techniques described herein may be implemented by hardware or software, or a combination of hardware and software. Thus, certain aspects or portions of an analysis machine for software safety analysis in accordance with the present disclosure may be implemented in one or more computer programs executable by a general purpose or dedicated microprocessor, micro-controller, or the like. A computer program according to an embodiment of the present invention includes a storage medium readable by a computer processor or the like, for example, a nonvolatile memory such as an EPROM, an EEPROM, a flash memory device, a magnetic disk such as an internal hard disk and a removable disk, a magneto-optical disk, and It may be implemented in a form stored in various types of storage media, including a CDROM disk. Further, the program code (s) may be implemented in assembly or machine language, and may also be implemented in the form of transmission via electrical wiring or cabling, optical fiber, or any other form of transmission medium.

Although an example embodiment of software risk analysis has been described primarily herein with reference to various figures, other similar embodiments may be used. All modifications and changes that fall within the true spirit and scope of the present invention are intended to be covered by the following claims.

Claims (10)

1. A computer-implemented method of safety analysis of electronic software,

   Receiving electronic software for the electronic device;

   Partitioning the electronic software into one or more code modules;

   Using an analysis machine, wherein the analysis machine is a learning machine pre-learned and trained by a plurality of risk metric data sets, which are related to vehicle functional safety, each of the risk metric data sets comprising a plurality of risk metric data. Measuring, for each said code module, risk metric data values corresponding to said risk metric data;

   For each said code module, based on said risk metric data values, respectively, using said analysis machine, determining a value indicating whether a hazard is present;

   Using the analysis machine, for each of the code modules, determining a value indicative of a risk based on one or more of the measured risk metric data values; And

   Generating a report on the safety of the electronic software using the value indicating the risk determined for each of the code modules

   Including, electronic software safety analysis method.
2. The method of claim 1,

   The risk metric data values include a risk level value for the code module, wherein the risk level value is defined based on one or more of a severity level value, a probability of occurrence value, and an implementation difficulty level value of the code module. Wherein the risk level value is one of i risk level values, the implementation difficulty level value is one of j implementation difficulty level values, and i and j are integers greater than or equal to two.
3. The method of claim 1,

   The risk metric data values are, for the code module, the total number of code lines (loc), McCabe cyclic complexity (v (g)), McCabe required complexity (ev (g)), McCabe design complexity (iv (g)). , The total number of Halstead operators and operands (n), Halstead program volume (v), Halstead program length (l), Halstead program difficulty (d), Halstead Intelligent content (i), Halstead programming effort (e), Halstead error estimation ( b), Halstead implementation time estimate (t), Halstead line count (lOCode), Halstead comment lines (lOComment), Halstead blank lines (lOblank), lines with both code and comments (IOCodeANDComment), number of unique operators A method for software safety analysis for electronics, comprising one or more values of (uniq_Op), unique operand (uniq_Opnd), total operator (total_Cp), total operand (tatal_Opand), and graph flow number (branchCount).
4. The method of claim 2,

   Generating a report on the safety of the electronic software using the value indicating the risk determined for each of the code modules. Calculating a local risk index of the code module.
5. The method of claim 4, wherein

   The local risk index for the code module is

   The local risk index = (the implementation difficulty level value of the code module + the risk level value of the code module) / (i + j)

   Electronic software safety analysis method, determined by
6. The method of claim 5,

   The step of generating a report on the safety of the electronic software using the value indicating the risk determined for the code module. Calculating a total risk index of the electronic software.
7. The method of claim 6,

   Dividing the electrical equipment software into one or more code modules includes dividing the electrical equipment software into n code modules, wherein the total risk index of the electronic equipment is

   Total risk index =

   

   Local Risk Index _i * 100

   Electronic safety analysis method, as determined by.
8. The method of claim 1,

   The step of preparing a report on the safety of the electronic software. And generating the report using information about a position indication of a dangerous code, a supplement of a dangerous code, and an expected input effort among one or more of the code modules.
9. A computer device, the computer device operable to carry out the method of claim 1.
10. A computer readable storage medium having stored thereon one or more instructions, wherein the one or more instructions, when executed by a computer, cause the computer to execute the method of any one of claims 1 to 8.

Images