KR101675986B1 - Method and apparatus for analyzing safety of automotive software - Google Patents

Abstract

According to the present invention, provided is a method for analyzing safety of automotive software in a computer, capable of providing correctness and safety based on a machine-learning or deep-learning technology. The method comprises the following steps: receiving input of automotive software; dividing the automotive software into one or more code modules; using an analysis machine to measure risk metric data values corresponding to each piece of risk metric data with respect to each code module, wherein the analysis module is a learning machine previously learned and trained by a plurality of risk metric data sets relating to safety of vehicle functions; using the analysis module to determine a value representing risk presence with respect to each code module based on the risk metric data values; using the analysis module to determine a value representing the risk presence with respect to each code module based on one or more of the measured risk metric data values; and using the value representing the risk presence determined to each code module to make a report about safety of the automotive software.

Description

[0001] METHOD AND APPARATUS FOR ANALYZING SAFETY OF AUTOMOTIVE SOFTWARE [0002]

BACKGROUND OF THE INVENTION 1. Field of the Invention [0002] The present invention relates to a software safety analysis method and apparatus for a vehicle electric field, and more particularly, to a method and apparatus for software safety analysis for a vehicle electric field based on machine learning.

In recent years, along with the diversification and advancement of software for vehicle electric field, the automotive electronics market is also rapidly growing. In addition, efforts have been made to improve the manufacturing efficiency of the vehicle electric field software and standardization efforts to prevent defects. For example, many automotive companies are developing software for the entire field based on the ISO 26262 automotive electrical / electronic system safety certification specification and the AUTOSAR development platform.

On the other hand, due to the nature of the battlefield software, it can cause damage that can not be recovered in the event of an error. In addition, various accidents and incidents caused by the errors of the battlefield software are occurring steadily, and the interest in the safety of the battlefield software is increasing day by day. In addition, due to the advancement and diversification of software for electric vehicles, damage caused by software defects or obstacles is becoming more and more serious, and accidents caused by software defects can damage the safety of customers and the image of automobile companies have. Therefore, it is important to predict the possibility of defects in the field-use software at the early stage of the life of the software, and to make it possible to correct them rapidly. Even in the case of software based on standards, forecasting and verifying these defects is a very important issue.

On the other hand, the task of analyzing and predicting defects in various kinds of software including automotive software has conventionally been manually performed by human hands. For example, in the case of on-board software, software experts have been at the level of manually checking each software module for adherence to the coding rules of the Motors Industry Software Reliability Association (MISRA) specification.

However, this manual analysis method has a problem that analysis accuracy is low and stability of analysis is difficult to expect in the current situation where the complexity of the code structure of software for electric field is increasing day by day. In addition, there is a problem that it is difficult to identify which part of the large-scale electric field software has to be repaired in an urgent manner, and it is difficult to efficiently allocate limited resources (for example, allocation of development / maintenance personnel) come.

Therefore, there is a need for an accurate, reliable, and automated method of analyzing safety software for battlefields. In addition, it is necessary to provide the analysis result in a way that allows the user to intuitively recognize and utilize it instantaneously so as to be able to refer to the prioritization of tasks for repairing defects of the battlefield software in the future.

According to one aspect of the present invention, there is provided a method for analyzing the safety of software for electronic devices, which is performed by a computer. The safety analysis method for software for electric field according to the present invention comprises the steps of: receiving software for electric field; Dividing software for the entire field into one or more code modules; Wherein the analysis machine-analysis machine is a learning machine previously trained and trained by a plurality of risk metric data sets related to vehicle function safety, each of the risk metric data sets including a plurality of risk metric data, Measuring risk metric data values corresponding to the risk metric data for a code module of the risk metric data module; For each code module, determining, based on the risk metric data values, a value indicative of risk, using an analysis machine; Using an analysis machine, for each code module, determining a value indicative of risk based on one or more of the measured risk metric data values; And generating a report on the safety of the overall software using a value indicating whether or not the risk is determined for each code module.

According to one embodiment of the present invention, the risk metric data values include a risk level value for the code module, and the risk level value is at least one of a severity level value, an occurrence probability value, and an implementation difficulty level value of the code module , The risk level value is a value of one of the i risk level values, the implementation difficulty level value is one of the j implementation difficulty level values, and i and j may be an integer of 2 or more.

According to one embodiment of the present invention, the risk metric data values are computed for the code module, the total number of code lines (loc), the McCabe cyclic complexity (v (g)), the McCabe essential complexity (ev (g) Halstead program volume (v), Halstead program length (l), Halstead program difficulty (d), Halstead Intelligent content (i), Halstead programming effort Halstead error estimate (b), Halstead implementation time estimate (t), Halstead line count (lOCode), Halstead annotation count (lOComment), Halstead bin count (lOblank) IOCodeANDComment), the number of unique operators (uniq_Op), the number of unique operands (uniq_Opnd), the total operator (total_Cp), the total operand (tatal_Opand), and the number of graph flows (branchCount).

According to an embodiment of the present invention, the step of generating a report on the safety of the software for the electric field using the value indicating the risk or not determined for each code module. And calculating a local risk index of the code module.

According to an embodiment of the present invention,

The local risk index for the code module,

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

Lt; / RTI >

According to an embodiment of the present invention, the step of generating a report on the safety of the software for the electric field using the value indicating the danger or not determined for the code module. And calculating a total risk index of the software for the battlefield.

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

로컬 위험 지수_i *100Total Risk Index =

Local Risk Index _i * 100

Lt; / RTI >

According to an embodiment of the present invention, the step of generating a report on the safety of the software for the electric field includes: Generating a report using information on the location of the risk code among the one or more code modules, a method of supplementing the risk code, and information on the expected input effort.

According to another aspect of the present invention, there is provided a computer apparatus operable to execute any one of the above-described methods for analyzing the safety of software for electric vehicles.

According to another aspect of the present invention there is provided a computer readable storage medium having stored thereon one or more instructions that when executed by a computer causes the computer to perform the method of any of the above- A computer readable storage medium is provided.

According to the present invention, an accurate and safe method for analyzing the safety of software for electric fields can be provided based on a machine learning or a deep learning technique. According to the present invention, the result of the safety analysis of the software for the electric field can be intuitively recognized by the user, and can be immediately utilized to make reference to the prioritization of tasks for repairing defects of the software for the battlefield , ≪ / RTI >

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a flow block diagram schematically illustrating the process of creating and utilizing an analysis machine for automatic reliability and safety analysis of software for electrical field, according to an embodiment of the present invention;
Figure 2 illustrates an exemplary set of risk data metrics to be used as input values in the generation and training of an analysis machine, in accordance with an embodiment of the present invention.
3 is a table showing examples of S _n data that can be used in an exemplary process of reducing metric data to be used for reliability or safety analysis of an analysis machine to sensitive metric data.
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. Hereinafter, when it is determined that there is a possibility that the gist of the present invention may be unnecessarily blurred, a detailed description of known functions and configurations will be omitted. In addition, it should be understood that the following description is only an embodiment of the present invention, and 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 in the present sense of the present invention. For example, elements in the singular may, unless the context clearly dictates a singular value, Should be understood as including the components. In addition, in the specification of the present invention, it is to be understood that terms such as "include" or "have" are intended to specify the presence of stated features, integers, steps, operations, components, It is not intended that the use of the term exclude the presence or addition of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.

In the embodiments described herein, 'block' or 'sub-unit' means a functional part that performs at least one function or operation, and may be implemented in hardware or software, or a combination of hardware and software. The plurality of "blocks" or "parts" may be embodied in at least one processor integrated with at least one software module, except for "blocks" or "parts" 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 to which this invention belongs. Commonly used predefined terms are to be interpreted as having a meaning consistent with the contextual meaning of the related art and are not to be construed as being excessively limited or extended unless explicitly defined otherwise in the specification of the present invention You should know.

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

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a flow block diagram schematically illustrating the process of creating and utilizing an analysis machine for automatic reliability and safety analysis of software for electrical field, according to an embodiment of the present invention;

As shown, at block 102, as a basic process for the creation of a full-length software analysis machine, elements related to vehicle function safety, such as those defined in ISO 26262 or functional safety elements defined in AUTOSAR, Elements of the various vehicle functional safety measures are collected and risk data metrics of the functional safety factors to be used as inputs in the subsequent generation and training of the analysis machine can be selected accordingly. The selection of risk data metrics for this functional safety can be done in a variety of ways, for example by utilizing domain experts or by interviewing.

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

Specifically, as shown, the risk data metrics to be used in the generation and training of the analysis machine include, for example, the total number of lines of code loc, McCabe cyclic complexity v (g), McCabe essential complexity ev (g) , Halstead program volume (v), Halstead program length (l), Halstead program complexity (d), Halstead Intelligent content (i), Halstead Programming effort (e), Halstead error estimation (b), Halstead implementation time estimation (t), Halstead line count (lOCode), Halstead comment line count (lOComment), Halstead blank line count (lOblank) The number of lines (IOCodeANDComment), the number of unique operators (uniq_Op), the number of unique operands (uniq_Opnd), the total operator (total_Cp), the total operand (tatal_Opand), the number of graph flows (branchCount) Of risk data metrics. According to an embodiment of the present invention, the risk level is a risk level defined according to the specification of each given code module, for example, a severity level indicating how serious an error of each code module causes damage, An occurrence probability indicating how much the probability of occurrence of damage caused by the damage occurs, and a difficulty level in implementing the code module. If the damage of the code module causes the risk of serious life, the severity level may be higher than that of the code module which causes minor damage or recurrence even if an error occurs due to the characteristics of the code module. Also, even in a code module having a high level of severity, 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 intended only to illustrate how to distinguish between levels of risk, but the invention is not so limited. Those skilled in the art will be able to think of 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 = normal; S2 = severe injury; S3 = Severe life risk

<Probability of occurrence>
E1 = very low probability; E2 = low probability; E3 = medium probability; E4 = high probability

<Implementation difficulty>
D1 = easy; D2 = medium; D3 = difficulty

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 above-described risk level, and a detailed description thereof will be omitted here. It will also be appreciated by those skilled in the art that the data metric shown in FIG. 2 is only one embodiment of the present invention, and that the present invention is not so limited.

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

At block 106, an analysis machine (Deep Treading machine) for automatic reliability and safety analysis of the electrical field software is initially designed and the analysis machine can be initially learned using the training data prepared at block 104. According to an embodiment of the present invention, an analysis machine can be designed according to an ANN or a support vector machine (SVM) technique, but the present invention is not limited thereto. Those skilled in the art will appreciate that the analytical machine can be implemented by various other deep-running schemes.

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

Meanwhile, regarding the analysis machine for automatic analysis of the reliability and safety of the software for the electric field according to the embodiment of the present invention, when the number of risk data metrics of the code module to be used in software analysis by the analysis machine is excessively large, Accurate and efficient modeling of analytical results can be difficult by increasing dimensionality. Conversely, if the number of risk data metrics in the code module to be used is too small, it may be difficult to find the exact association between the input and the analysis result. Thus, it may be more desirable to limit the risk data metrics of each code module to be used in the analysis of the analysis machine to sensitive and sensitive data metrics related to the reliability and safety of the code module concerned. That is, the analysis machine can find out which of the risk metric data that can be used for the analysis greatly influences the analysis result even if the value is slightly changed, and can restrict such sensitive data to be used in the analysis machine .

For example, if the total number of metric data used in the initial generation of the analysis machine is d and each training data set with d input data sets is i, then each nth (1? N The sensitivity of the input value of the position (risk metric data value) to the analysis result can be determined according to the following method.

DS_k S _n =

DS _k

_{DS k = O (I k)} -O (I k + Δ kn)

I _k : kth input sample set

O ( _Ik ): the trained machine output value of the kth input sample set

I _k + [Delta] _kn : In the kth input sample set, the input sample set is obtained by adding a small constant value Δ to the nth value of the kth input sample set

O (I _k + [Delta] _kn ): For the kth input sample set, the trained machine output value for the input sample set plus the small constant value [Delta]

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

Referring again to FIG. 1, in block 110, a safety analysis of the software for the battlefield using the analysis machine is performed. Although not specifically shown, according to one embodiment of the present invention, the safety analysis results of the software at block 108 may be fed back into block 106 to update the analysis machine. The process of analyzing the safety of the overall electric vehicle software will be described in detail with reference to FIG.

At block 112, the results of the analysis performed by the analysis machine at block 110 may be reported to the user in a useful and intuitive manner. For example, the report of the analysis result may include the analysis of the analysis result, the achievement target and the indication of the current level, and the future action plan according to the achievement goal.

3 is a table showing examples of S _n data that may be used in an exemplary process of reducing metric data to be used for reliability or safety analysis of the analysis machine to sensitive metric data, as described above. In the case of 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 (equal to the risk level out of the risk data metrics of FIG. 2) Delta] is assumed to be 0.1, and only data having a value of S _n of 0.1 or more is defined 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 can be reduced to fourteen (i.e., loc, branchCount, iv (g), v, lOCodeAndComment, lOCode, uniq_Opnd, d, , e, v (g), n, total_Opnd, uniq_Op). These reductions can limit input to values that are highly correlated with the analysis results, enabling 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. The analysis machine 400 includes an input unit 402, a risk data metric measurement unit 404, a risk analysis unit 406, and a report generation unit 408.

According to one embodiment of the present invention, in the input unit 402, a code input of the prepared full-length software can be received. The input software may be completed or may be software for a battlefield under development. The software may include one or more code modules. In the input unit 402, the input software may also be divided into one or more code modules, such as one or more functions or the like.

According to an embodiment of the present invention, in the risk data metric measurement unit 404, the risk data metric measurement unit 404 calculates a risk data metric for each code module (for example, each function unit) (Or the value of such limited sensitive metric data if the risk data metrics to be used in the analysis are limited to sensitive data) of the functional safety elements of the functional safety element used to create the analytic machine. For example, the risk data metric measurer 404 calculates a risk data metric for each code module of the input software by comparing the total code line count loc, McCabe cyclic complexity v (g), McCabe essential complexity ev (g) Halstead program volume (v), Halstead program length (l), Halstead program difficulty (d), Halstead Intelligent content (i), Halstead programming (m), McCabe design complexity (iv (g)), Halstead operator and total number of operands Halstead error estimate (b), Halstead implementation time estimate (t), Halstead line count (lOCode), Halstead comment line count (lOComment), Halstead blank line count (lOblank) Risks such as the number (IOCodeANDComment), the number of unique operators (uniq_Op), the number of unique operands (uniq_Opnd), the total operator (total_Cp), the total operand (tatal_Opand), the number of graph flows (branchCount), and the risk level One or more of the data metric values may be automatically measured.

According to an embodiment of the present invention, the risk analysis unit 406 uses the risk data metrics of each code module measured by the risk data metric measurement unit 404, including the risk level values measured for each code module The risk is analyzed for each code module. The analyzed result can be output as a value of True or False indicating that the corresponding module is dangerous for each code module.

According to an embodiment of the present invention, the report creating unit 408 can automatically generate a report on the risk of the input software. According to an embodiment of the present invention, the report generating unit 408 generates a risk analysis result of each code module obtained by the risk analysis unit 406 (i.e., a True or False value for each code module) A risk level value of each code module of the input software measured by the risk data metric measurement unit 404 and the implementation difficulty value used to measure the risk level value may be used to generate a report. According to an embodiment of the present invention, in the report generating unit 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, A report on the risk of input software, including the calculated local risk index and the total risk index, may be generated.

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 number + total risk level number)

For example, as in the embodiment described above with reference to Table 1, if the overall implementation difficulty level is 3, then a particular code module is the second stage, i.e., the second most difficult stage (e.g., D2) The local risk index for the particular code module may be (2 + 3) / (3 + 5) = 0.625 when the particular code module is the third risk level (e.g., 2).

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 one software code.

로컬 위험 지수_i *100Total Risk Index =

Local Risk Index _i * 100

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

It should be noted that the method of calculating the above-described risk index is only one embodiment of the present invention, and the present invention is not limited thereto. The local risk index of each code module thus calculated and the total risk index of the entire software can be used by the report generating unit 408 to generate a report on the risk of the software as described above. According to an embodiment of the present invention, the report may include at least one of the above-described information, for example, a risk analysis result of each code module, a local risk index of each code module, and / Location indication, supplementary measures, and expected 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, rearranged and replaced without departing from the scope of the present invention. For example, the various techniques described herein may be implemented in 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 with one or more computer programs executable by a general purpose or special purpose microprocessor, micro-controller, or the like. A computer program according to an embodiment of the present invention may be stored in a storage medium readable by a computer processor or the like such as a nonvolatile memory such as EPROM, EEPROM, flash memory device, a magnetic disk such as an internal hard disk and a removable disk, CDROM disks, and the like. Also, the program code (s) may be implemented in assembly language or machine language, and may be implemented in a form that is transmitted over electrical wiring or cabling, optical fiber, or any other form of transmission medium.

Although exemplary embodiments of the software risk analysis are mainly described herein with reference to various drawings, other similar embodiments may be used. And all changes and modifications that fall within the true spirit and scope of the present invention are intended to be embraced by the following claims.

402: Input unit
404: Risk data metric measurement unit
406: Risk Analysis Department
408:

Claims (10)

1. A method for analyzing safety of software for a field, which is performed by a computer,
Receiving software for the battlefield;
Dividing the overall software into one or more code modules;
An analysis machine, wherein the analysis machine is a learning machine previously trained and trained by a plurality of risk metric data sets related to vehicle function safety, each of the risk metric data sets comprising a plurality of risk metric data Measuring, for each of the code modules, the risk metric data values corresponding to the risk metric data;
Determining, for each of the code modules, a value indicative of risk, using the analysis machine, based on the risk metric data values;
Using the analysis machine, for each of the code modules, determining a value indicative of risk based on at least one of the measured risk metric data values; And
Calculating a local risk index of the code module using a value indicating the risk level determined for each of the code modules,
Wherein the local risk index for the code module,
The local risk index = (the implementation difficulty level value of the code module + the critical level value of the code module) / (i + j)
The method comprising the steps of: The method according to claim 1,
Wherein the risk metric data values comprise a risk level value for the code module and the risk level value is defined based on at least one of a severity level value, an occurrence probability value, and an implementation difficulty level value of the code module Wherein the danger 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 an integer of 2 or more. The method according to claim 1,
Wherein the risk metric data values comprise at least one of a total number of lines of code (loc), McCabe cyclic complexity (v (g)), McCabe essential complexity (ev (g)), McCabe design complexity (iv , Halstead Operator and Total Operands (n), Halstead Program Volume (v), Halstead Program Length (l), Halstead Program Difficulty (d), Halstead Intelligent Content (i), Halstead Programming Effort b), Halstead implementation time estimate (t), Halstead line count (lOCode), Halstead comment line count (lOComment), Halstead blank line count (lOblank), Number of lines with both code and comment (IOCodeANDComment) (uniq_Op), unique operand count (uniq_Opnd), total operator (total_Cp), total operand (tatal_Opand), and graph flow count (branchCount). The method according to claim 1,
The method comprises:
Further comprising the step of generating a report on the safety of the software for the field using the value indicating the danger or not determined for the code module. delete 5. The method of claim 4,
The step of generating a report on the safety of the field-use software, using a value indicating the risk level determined for the code module. And calculating a total risk index of the software for the battlefield. The method according to claim 6,
Wherein dividing the overall software into one or more code modules comprises partitioning the overall software into n code modules,
Total Risk Index =

Local Risk Index _i * 100
The method comprising the steps of: 5. The method of claim 4,
The step of preparing a report on the safety of the above-mentioned field use software is as follows. Generating the report using the information on the location of the risk code, the risk code supplement, and the expected input effort among at least one of the code modules. A computer device operable to perform the method of any one of claims 1 to 4 and 6 to 8. 15. 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 perform the method of any one of claims 1 to 4 and 6 to 8 &Lt; / RTI &gt;

Images