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

Abstract

Provided is a method for analyzing the safety of an automotive software, performed by a computer. The safety analysis method of the electronic software includes the steps of: receiving an input of the electronic software; dividing the battlefield software into one or more code modules; Using an analysis machine, the analysis machine is a learning machine previously trained and trained by a plurality of risk metric data sets related to vehicle functional safety, each risk metric data set including a plurality of risk metric data, each measuring, for a code module of , risk metric data values corresponding to the risk metric data; determining, for each code module, based on the risk metric data values, respectively, a value indicating whether or not there is a risk, using the analysis machine; determining, using the analysis machine, for each code module, a value indicative of whether or not there is a risk based on one or more of the measured risk metric data values; And by using a value indicating whether or not the determined risk for each code module, it may include the step of creating a report on the safety of the electronic software.

Description

Software safety analysis method and device for electric field

The present invention relates to a method and apparatus for software safety analysis for automotive electrical equipment, and more particularly, to a method and apparatus for software safety analysis for automotive electronic equipment based on machine learning.

In recent years, along with the diversification and advancement of automotive electronic software, the automotive electronic equipment market is also rapidly growing. In addition, standardization efforts are continuing to improve manufacturing efficiency and prevent defects in automotive software. For example, many automobile companies are developing electronic software based on the ISO 26262 automotive electrical/electronic system safety certification standard and AUTOSAR development platform.

On the other hand, due to the nature of the software for the battlefield, when an error occurs, it can cause irreparable damage. In addition, various accidents and incidents due to errors in the electronic software are constantly occurring, and accordingly, interest in the safety of the electronic software is increasing day by day. In addition, with the advancement and diversification of electronic software, the damage caused by software defects or failures is becoming more and more serious. have. Therefore, it is important to predict the possibility of defects in the electronic software at the early stage of the software's lifespan and to be able to fix it quickly, and even in the case of software written based on standards, predicting and verifying the possibility of such defects is a very important issue.

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 case of automotive software, software experts have been limited to manually checking each software module for compliance with the coding rules specified by the Motors Industry Software Reliability Association (MISRA).

However, such a manual analysis method has a problem in that analysis accuracy is low and analysis stability is difficult to expect in the current situation in which the complexity of the code structure of the electronic software is increasing day by day. In addition, there is a problem in that it is difficult to identify which part of the large-scale electronic software is urgently required to repair defects, and there is a difficulty in the efficient allocation of limited resources in the software development/repair part (eg, allocation of development/maintenance personnel). come.

Therefore, there is a need for an accurate and stable, automated safety analysis method for automotive software. In addition, it is necessary to provide the analysis result in such a way that the user can intuitively recognize it and utilize it immediately for reference in prioritizing work for repairing defects in the electronic software in the future.

According to one aspect of the present invention, there is provided a method for analyzing the safety of electronic software, performed by a computer. The safety analysis method of the electronic software according to the present invention comprises the steps of: receiving an input of the electronic software; dividing the battlefield software into one or more code modules; Using an analysis machine, the analysis machine is a learning machine previously trained and trained by a plurality of risk metric data sets related to vehicle functional safety, each risk metric data set including a plurality of risk metric data, each measuring, for a code module of , risk metric data values corresponding to the risk metric data; determining, for each code module, based on the risk metric data values, respectively, a value indicating whether or not there is a risk, using the analysis machine; determining, using the analysis machine, for each code module, a value indicative of whether or not there is a risk based on one or more of the measured risk metric data values; and creating a report on the safety of the electronic software using a value indicating whether or not there is a risk determined for each code module.

According to an embodiment of the present invention, the risk metric data values include a risk level value for a code module, wherein the risk level value includes at least one of a severity level value of the code module, an occurrence probability value, and an implementation difficulty level value. is defined based on , 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 may be integers of 2 or more.

According to an embodiment of the present invention, the risk metric data values are, for a code module, the total number of lines of code (loc), the McCabe cyclic complexity (v(g)), the McCabe essential complexity (ev(g)), and the 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 ( 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 number of graph flows (branchCount).

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

According to one embodiment of the present invention,

The local risk index for the code module is:

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

can be determined by

According to an embodiment of the present invention, the step of creating a report on the safety of the electronic software using a value indicating whether the code module is determined to be dangerous is. calculating a total risk index of the battlefield software.

According to an embodiment of the present invention, the step of dividing the dedicated software into one or more code modules includes dividing the dedicated software into n code modules, and the total risk index of the dedicated software is

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

Local risk index _i *100

can be determined by

According to an embodiment of the present invention, the step of creating a report on the safety of the electronic software is. The method may include generating a report using information about the indication of the location of the risk code among the one or more code modules, the supplementation plan for the risk code, and the expected input effort.

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

According to another feature of the present invention, as a computer-readable storage medium storing one or more instructions, when the one or more instructions are executed by a computer, the computer causes the computer to use any one of the above-described methods for safety analysis of electronic software. A computer-readable storage medium for executing the

According to the present invention, based on machine learning or deep learning technology, an accurate and safe safety analysis method of electronic software can be provided. According to the present invention, the result of the safety analysis of the electronic software can be intuitively recognized by the user and can be used immediately for reference in determining the priority of the task for repairing the defects of the electric vehicle software in the future. , can be provided.

1 is a flow block diagram schematically showing a process of generating and using an analysis machine for automatic analysis of reliability and safety of electronic software, according to an embodiment of the present invention.
2 is a diagram illustrating an exemplary set of risk data metrics to be used as input values in the creation and training of an analytics machine, in accordance with an embodiment of the present invention.
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 an analysis machine into 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 risk of unnecessarily obscuring the gist of the present invention, detailed descriptions of already known functions and configurations will be omitted. In addition, it should be understood that the contents described below are only related to one embodiment of the present invention, and the present invention is not limited thereto.

The terminology used herein is only used to describe specific embodiments and is not intended to limit the present invention. For example, elements expressed in the singular are plural unless the context clearly means only the singular. It should be understood as a concept including components. In addition, in the specification of the present invention, terms such as 'comprise' or 'have' are only intended to designate that the features, numbers, steps, operations, components, parts, or combinations thereof described in the specification exist, and such The use of the term is not intended to exclude the possibility of the presence or addition of one or more other features or numbers, steps, operations, 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 as hardware or software or a combination of hardware and software. A plurality of 'blocks' or 'units' may be integrated into at least one software module and implemented by at least one processor, except for 'blocks' or 'units' that need to be implemented with specific hardware.

In addition, unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. It should be noted that commonly used terms defined in the dictionary should be interpreted as having meanings consistent with the meanings in the context of the related art, and are not to be interpreted in an unduly limited or expanded manner unless explicitly defined otherwise in the specification of the present invention. should know

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

1 is a flow block diagram schematically showing a process of generating and using 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 process for generating an automotive software analysis machine, elements related to vehicle functional safety, for example, functional safety elements defined in ISO 26262 or functional safety elements defined in AUTOSAR are selected. Various vehicle functional safety-related factors are collected, including, and thus risk data metrics of functional safety factors can be selected to be used as input in the generation and training of the later analysis machine. The selection of risk data metrics related to functional safety may be made in various ways, for example, by using 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 analytics machine, according to an embodiment of the present invention, is shown in FIG. 2 . As shown in FIG. 2 , an input value for generating and training an analysis machine may include 22 risk data metrics for a code module.

Specifically, as shown, the risk data metrics to be used in the generation and training of the analytic machine include, for example, the total number of lines of code (loc), McCabe cyclic complexity (v(g)), McCabe essential complexity (ev(g)) , McCabe design complexity (iv(g)), Halstead operator and total number of 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), having both code and comments Number of lines (IOCodeANDComment), number of distinct operators (uniq_Op), number of distinct operands (uniq_Opnd), total operators (total_Cp), total operands (tatal_Opand), number of graph flows (branchCount), and code module risk level (Risk Level) of risk data metrics may be included. According to an embodiment of the present invention, the risk level is a risk level defined according to the specification of each code module given, for example, a severity level indicating how serious damage is caused by a failure of each code module, and the error level of such code module. It may be a value that is predefined by the occurrence probability indicating how probable the damage is caused, the level of difficulty in implementing the corresponding code module, and the like. Due to the nature of the code module, if the damage that can occur in the event of an error in the corresponding code module is a serious risk to life, the severity level may be higher than that of the code module, which only causes minor damage or minor injuries even if an error occurs. Also, even if the code module has a high severity level, if the probability of occurrence of such a code module is very low, the overall risk level may be low. The table below is for illustrative purposes only, and the present invention is not limited thereto. Those skilled in the art may come up with a method of classifying risk levels in various forms in consideration of 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 = light; S2=severe; S3=serious life threatening

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

<Implementation Difficulty>
D1=easy; D2=medium; D3=difficult

A person 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 level described above, and detailed descriptions thereof will be omitted herein. In addition, those skilled in the art will appreciate that the data metric shown in FIG. 2 is only one embodiment of the present invention, and the present invention is not limited thereto.

Returning again to FIG. 1 , at block 104 , based on the definition of each risk data metric defined at block 102 , specific learning and training data may be prepared to be used in the creation of the analytics machine. According to an 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.

In block 106 , an analysis machine (deep learning machine) for automatic analysis of reliability and safety of the battlefield software is initially designed, and the analysis machine may be initially trained using the training data prepared in block 104 . According to an embodiment of the present invention, an analysis machine may be designed according to an artificial neural network (ANN) or a support vector machine (SVM) technique, but the present invention is not limited thereto. Those skilled in the art will know that the analysis machine may be implemented by various other deep learning methods.

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 iteratively into the machine design and learning phase of block 106 and the analysis machine may be modified accordingly. As this process of iterative machine modifications according to blocks 106 and 108 is performed, the creation of the code safety analysis machine may be completed.

On the other hand, in relation to the analysis machine for automatic analysis of reliability and safety of electronic software according to an embodiment of the present invention, when the number of risk data metrics of the code module to be used in software analysis by the corresponding analysis machine is too large, It can be difficult to accurately and efficiently model the analysis result value by increasing the dimension. Conversely, if the number of risk data metrics of the code module to be used is too small, it may be difficult to find an accurate correlation between the input and the analysis result. Therefore, it may be more preferable 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 closely related to the reliability and safety of the corresponding code module. That is, among the risk metric data that the analysis machine can use for analysis, it is possible to find out which risk metric data greatly affects the analysis result even if its value changes even slightly, and to 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 there are i training data sets each having d input data sets, each nth (1≤n ≤d) The sensitivity of the location input value (risk metric data value) to the analysis result may be determined according to the following method.

DS_k S _n =

DS _k

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

I _k : the kth input sample set

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

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

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

According to the above formula, among the risk data metrics belonging to the input sample set, which of the sensitive risk data metrics has a S _n value greater than or equal to a predetermined value, that is, a sensitive risk data metric that greatly affects the output result value of the analysis machine even if the given value changes slightly? can be found

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

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

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 an analysis machine into 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 metrics of the input data used for generation of the analysis machine is 21 (the same as the risk level among the risk data metrics of Fig. 2), a constant value It is assumed that Δ is 0.1, and only data in which the value of S _n is 0.1 or more is designated as sensitive data. In such a case, the data selected to be included in the input data metric set again based on the shown table 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 enable more efficient and accurate analysis by limiting the input to values highly correlated with the analysis result.

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 creation unit 408 .

According to an embodiment of the present invention, the input unit 402 may receive a code input of the written electronic software. The input software may be written or developed for battlefield software. Software may include one or more code modules. In the input unit 402, the inputted software may also be divided into one or more code modules, such as one or more functions, and the like.

According to an embodiment of the present invention, in the risk data metric measurement unit 404, for each code module (eg, each function unit) of the software input and divided in the input unit 402, block 102 of FIG. The value of each of the risk data metrics of the functional safety element selected from and used to create the analysis machine (or the value of the limited sensitive metric data when the risk data metrics to be used for analysis are limited to sensitive data) may be measured. For example, in the risk data metric measurement unit 404, for each code module of the inputted software, the total number of code lines (loc), McCabe cyclic complexity (v(g)), McCabe essential complexity (ev(g)), McCabe design complexity (iv(g)), Halstead operators and total number of operands (n), Halstead program volume (v), Halstead program length (l), Halstead program difficulty (d), Halstead Intelligent content (i), Halstead programming Effort (e), Halstead error estimate (b), Halstead implementation time estimate (t), Halstead line count (lOCode), Halstead comment lines (lOComment), Halstead blank lines (lOblank), lines with both code and comments Risks such as count (IOCodeANDComment), number of distinct operators (uniq_Op), number of distinct operands (uniq_Opnd), total operator (total_Cp), total operand (tatal_Opand), number of graph flows (branchCount), and risk level (Rist 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 value measured for each code module. Therefore, the risk is analyzed for each code module. 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 an embodiment of the present invention, the report creation unit 408 may automatically create a report on whether the inputted software is at risk. According to an embodiment of the present invention, in the report preparation unit 408, the risk analysis result of each code module obtained by the risk analysis unit 406 (that is, True or False values for each code module) together with, A report may be created using the risk level value of each code module of the input software measured by the risk data metric measuring unit 404 and the implementation difficulty value used to measure the risk level value. According to an embodiment of the present invention, in the report creation 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 can be made on whether the input software is at risk, including a calculated local risk index and a total risk index.

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

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

For example, as in the embodiment described above with reference to Table 1, when the overall implementation difficulty level is three, a certain code module is the second stage, that is, the second highest difficulty stage (eg D2), and the overall risk level In these five cases, if the specific code module is the third risk level (eg, 2), the local risk index for the specific code module may be (2+3)/(3+5)=0.625.

In addition, it is possible to calculate a total risk index for the entire software code by averaging each local risk index of each code module belonging to a certain 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% can be

It should be understood that the method for 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 calculated in this way and the total risk index of the entire software may be used by the report writing unit 408 to prepare a report on whether or not the corresponding software is at risk, as described above. According to an embodiment of the present invention, in the report creation, the risk code is generated along with the above-mentioned information, for example, the risk analysis result of each code module, the local risk index of each code module, and/or the total risk index of the entire software. Information regarding location indications, supplementary measures, and expected input efforts may be further included.

As will be appreciated by those skilled in the art, the present invention is not limited to the examples described herein, and various modifications, reconstructions and substitutions can be made 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. Accordingly, certain aspects or portions of the analysis machine for software safety analysis according to the present disclosure may be implemented as 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, nonvolatile memory such as EPROM, EEPROM, flash memory device, magnetic disk such as built-in hard disk and removable disk, magneto-optical disk, and It may be implemented in a form stored in various types of storage media including a CDROM disk and the like. In addition, the program code(s) may be implemented in assembly language or machine language, and may be implemented in a form transmitted through electric wiring, cabling, optical fiber, or any other type of transmission medium.

Although this specification has primarily been described with reference to various figures for exemplary embodiments of software risk analysis, other similar embodiments may be utilized. All modifications and variations falling within the true spirit and scope of the present invention are intended to be encompassed by the following claims.

402: input unit
404: Risk Data Metric Measure Unit
406: risk analysis unit
408: report writing unit

Claims (10)

A method for safety analysis of software for an electric vehicle, performed by a computer, comprising:
receiving an input of the battlefield software;
dividing the electronic software into one or more code modules;
measuring, using an analysis machine, for each said code module, risk metric data values corresponding to risk metric data;
determining, for each of the code modules, a value indicative of whether or not there is a risk, respectively, using the analysis machine, based on the risk metric data values;
determining, using the analysis machine, for each of the code modules, a value indicative of whether or not there is a risk, based on one or more of the measured risk metric data values; and
Comprising the step of creating a report on the safety of the electronic software by using the value indicating whether the risk determined for each of the code module,
The analysis machine comprises the steps of: collecting vehicle functional safety factors and selecting a plurality of risk metric data; preparing learning and training on a plurality of risk metric data sets including the plurality of risk metric data; designing and learning As a step, designing a machine by a deep learning method and learning using the plurality of risk metric data sets, and testing the machine and analyzing the error rate are generated including the steps of feeding back to the design and learning step ,
the risk metric data values include a risk level value for the code module, the risk level value being defined based on one or more of a severity level value, an occurrence probability value, and an implementation difficulty level value of the code module; the risk level value is one of i risk level values, the implementation difficulty level value is one of j implementation difficulty level values, i and j are integers of 2 or more,
generating the report includes calculating a local risk index for the code module, wherein the local risk index for the code module includes:
The local risk index = (the implementation difficulty level value of the code module + the risk level value of the code module) / (i + j)
determined by
Software safety analysis method for battlefield. delete According to claim 1,
The risk metric data values are, for the code module, total number of lines of code (loc), McCabe cyclic complexity (v(g)), McCabe essential complexity (ev(g)), McCabe design complexity (iv(g)) , Halstead operator and total number of 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), unique operators (uniq_Op), number of unique operands (uniq_Opnd), total operator (total_Cp), total operands (tatal_Opand), and graph flow count (branchCount). delete delete According to claim 1,
The step of creating a report on the safety of the electric vehicle software by using the value indicating whether the code module is at risk. Comprising the step of calculating the total risk index of the battlefield software, the safety analysis method for automotive software. 7. The method of claim 6,
The step of dividing the dedicated software into one or more code modules includes dividing the dedicated software into n code modules, and the total risk index of the dedicated software is
Total Risk Index =

Local risk index _i *100
Determined by the battlefield software safety analysis method. According to claim 1,
The step of creating a report on the safety of the electronic software is. Comprising the step of generating the report by using the information about the location indication of the dangerous code among the one or more code modules, the supplementary method of the dangerous code, and the expected input effort, the battlefield software safety analysis method. 9. A computer device operable to carry out the method of any one of claims 1, 3 and 6 to 8. 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 execute the method of any one of claims 1, 3 and 6 to 8. a computer-readable storage medium.

Images