KR102066868B1 - Method and apparatus for simulating safety of automotive software to obtain a goal reliability index - Google Patents

Abstract

A method is provided for simulating the safety of an electronic software code module built on a standard platform, performed by a computer, to meet a target reliability index. The method of the present invention receives a software code module and standard platform identification information related to the creation of the software code module, and uses an analysis machine to determine whether the software code module is at risk, so that the software code module is at risk. Obtaining safety information of the software code module from a database, wherein the safety information is obtained based on the standard platform identification information; Calculating a category indicator index for each category into which the software code module is classified; And receiving a target reliability index, and calculating a set of safety mechanisms that allow each category marker index to achieve the target reliability index.

Description

METHOD AND APPARATUS FOR SIMULATING SAFETY OF AUTOMOTIVE SOFTWARE TO OBTAIN A GOAL RELIABILITY INDEX}

The present invention relates to software safety analysis for vehicle electronics, and more particularly, to a method and apparatus for simulating safety of vehicle electronics software developed based on a standard platform to satisfy a target reliability index.

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. In particular, many automotive companies are developing electronic software for electronics based on the ISO 26262 automotive electrical / electronic system safety certification standard and the AUTOSAR BSW development platform.

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 predict the defect potential of electronic software early in the life of the software and to be able to fix it quickly.In the case of software written based on the AUTOSAR BSW development platform, the prediction and verification of such defect potential is very important. It is an issue.

By the way, the work of analyzing and predicting the defects of various software including the vehicle software has conventionally been 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, the results of such manual analysis are only provided in a simple list form, which makes it difficult for real software developers / maintenants to identify which parts of a large-scale electronic software are urgently needed. In addition, there is a difficulty in efficiently allocating limited resources (eg, distribution of development / maintenance personnel) in the software development / maintenance part.

On the other hand, Korean Patent No. 10-1834247 analyzes the safety of the automated and secure electronic software for accurate and stable, and the results of the analysis can be intuitively recognized by the user, and immediately utilized it, and later defects of the electronic software for the future. The method is provided in a way that can be referred to in order to prioritize the work for repair, but the information is analyzed in more detail so that the developer can see and judge the result instead of simply listing the software code analysis result. Function is needed.

KR 10-1834247 B

Therefore, in the present disclosure, a safety mechanism rule may be used to assist the decision maker to determine the priority of the risk analysis result for the safety of the electronic software code, and to decide whether to access and modify the limited resources. We want to provide a way to model information.

In addition, in the present disclosure, using the value of the current risk index and the target reliability index to be achieved, which safety mechanism rules should be improved by the user (developer) to achieve the target, and how much effort cost (time) is required. We want to provide a way to simulate it.

According to one aspect of the present invention, there is provided a method for simulating a computer implemented by a computer, the safety of the electronic software code module written based on the standard platform to meet the target reliability index. The method of the present invention receives a software code module and standard platform identification information related to the creation of the software code module, and uses an analysis machine to determine whether the software code module is at risk, so that the software code module is at risk. Obtaining safety information of the software code module from a database, wherein the safety information is obtained based on the standard platform identification information; Calculating a category indicator index for each category into which the software code module is classified; And receiving a target reliability index, and calculating a set of safety mechanisms that allow each category marker index to achieve the target reliability index.

According to an embodiment of the present invention, the category marker index is calculated based on the global index for each category, labor cost, code size, and risk level of the code module.

According to an embodiment of the present invention, the standard platform may be an AUTOSAR BSW, and the standard platform identification information may be a module ID of an AUTOSAR BSW.

According to an embodiment of the present invention, the database may store information for mapping standard platform identification information to one safety mechanism among a plurality of safety mechanisms defined in Safe Automotive soFtware archiTecture (SAFE) ISO 26262. The database may further store one or more predefined safety information corresponding to one mapped safety mechanism.

According to one embodiment of the present invention, one or more predefined safety information corresponding to one mapped safety mechanism may be updatable.

According to an embodiment of the present invention, the one or more safety information predefined in correspondence with the mapped one safety mechanism may include at least one of priority of defect repair, difficulty of implementation, and input effort time.

According to an embodiment of the present invention, the priority of defect repair and the difficulty of implementation may respectively correspond to one of a plurality of predetermined levels.

According to one embodiment of the present invention, a plurality of safety mechanisms defined in SAFE ISO 26262 may be classified into a predetermined number of categories, and one mapped safety mechanism may belong to one category of the predetermined number of categories.

According to one embodiment of the present invention, the report includes a name of one mapped safety mechanism, a description of one mapped safety mechanism, a category of one mapped safety mechanism, and a defect repair of one mapped safety mechanism. It may include at least one of a priority, a difficulty of implementing one mapped safety mechanism, and an input effort time of one mapped safety mechanism.

According to another feature of the invention, there is provided a computer device, which is operable to carry out any of the methods described above.

According to another feature of the 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 execute the method of any one of the preceding methods. A readable storage medium is provided.

According to the present invention, among the guidelines to be secured by the software developer in terms of software analysis to secure safety as a result of the risk analysis of the code, the intention of the first to be made according to the implementation difficulty, input effort time, defect repair priority Ways to refer to the decision may be provided.

According to the present invention, a method that can be applied to not only the field of software development in the field of electronics but also to the field to perform rule-based static analysis of software code 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 functional block diagram of a software reliability and safety analysis machine 300, in accordance with an embodiment of the present invention.
4 is a diagram illustrating a group of safety mechanisms to be applied according to a relationship between priority and implementation difficulty according to an embodiment of the present invention.

Hereinafter, exemplary 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 invention. For example, a component expressed in the singular should be understood as a concept including a plurality of components unless the context clearly indicates the singular. 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' refers to 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. In addition, a plurality of 'blocks' or 'units' may be integrated into at least one software module and implemented as at least one processor, except for 'blocks' or 'units' that need to be implemented with 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 The 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 error 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 = normal; S2 = medium phase; S3 = Serious Danger

<Probability>
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. In accordance with another embodiment of the present invention, it should be appreciated that more or less various risk data metrics may be used to generate and train the analysis machine, depending on the design criteria of the analysis machine. 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.

In 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. 3.

3 is a functional block diagram of a software reliability and safety analysis machine 300, in accordance with an embodiment of the present invention. As shown, the analysis machine 300 includes an analysis code information input unit 302, a risk data metric measurement unit 304, a risk analysis unit 306, a code module safety feature acquisition unit 308, a category marker calculation unit ( 310 and the target exponent simulation unit 312.

According to one embodiment of the present invention, the analysis code information input unit 302, the code of the generated electrical equipment software and the platform information (for example, in the case of development software based on AUTOSAR BSW based on each software code module based on the code development) Each corresponding AUTOSAR BSW module ID, etc.) may be received. In this case, the input software may be completed or electronic equipment under development. The software may include one or more code modules. The analysis code information 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 304, for each code module (e.g., each function unit) of the software input and divided by the analysis code information input unit 302, the block of Figure 1 The value of each of the risk data metrics of the functional safety factor selected at 102 and used to create the analysis machine (or the value of such limited selected metric data if the risk data metrics to be used for analysis are limited to predetermined data) is selected. Can be measured. For example, in the risk data metric measuring unit 304, 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 (total_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 306 uses risk data metrics of each code module measured by the risk data metric measurer 304, 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 in which the corresponding module quantifies the degree of risk for each code module.

On the other hand, according to an embodiment of the present invention, the code module safety feature acquisition unit 308, the platform information (for example, AUTOSAR BSW-based development that is the basis of the corresponding code module development received from the analysis code information input unit 302) In the case of a software code module, a corresponding AUTOSAR BSW module ID, etc.) of the corresponding software code module may be received, and the safety feature information of the corresponding code module may be obtained. Although not specifically illustrated, according to an embodiment of the present invention, the platform information which is the basis of each code module development may be predefined and stored together with the code module safety features related thereto, and the analysis code information input unit ( 302 may retrieve such predefined and stored information based on the given platform information and obtain safety feature information of the corresponding code module. Although not specifically illustrated, according to an embodiment of the present invention, the above-described information may be recorded in a storage inside the software reliability and safety analysis machine or in an external separate storage device.

In this regard, Deliverable D3.6.b: Safety Code Generator Specification of the SAFE_D3.6.b.pdf of the ISO 26262 guideline Safety Automotive software architecture (SAFE), which is distributed in Europe, provides fault-tolerant safety mechanisms for vehicle software. It is divided into three categories, namely, Error Detection and Error Handling, and each of these detailed requirements are listed and defined as 36 in total. The following table is a classification table of the SAFE ISO 26262 Safety Mechanism, it should be understood that it is merely provided by way of example to aid the understanding of the present invention, not intended to limit the present invention. In addition, according to another embodiment of the present invention, safety mechanisms may be defined by categorizing them into B, 1, 2, 3, and 4 categories defined in standards in the field of machine safety, such as ISO 13849.

No One Fault Avoidance Freedom From Interference Partitioning 2 Replication 3 Barrier Interlock Data InterLock 4 Control Flow InterLock 5 Error Detection Stateless Error Detection Checksum Parity checker 6 CRC 7 Comparison 8 Self test Software Self Test RAM Self Test 9 Hardware Self Test ROM Self Test 10 Range check 11 Challenge Response Check 12 Message Readback Check 13 Stateful Error Detection Plausibility Analytic Redundancy 14 Actuator Monitoring 15 Sensor Plausibility Sensor Correlation 16 Sensor Reationality Check 17 Gradient checker 18 Logical Monitoring Logical Control Flow Monitoring (Logical Autosar WDM) 19 Logical Data Flow Monitoring Data Sequence Monitor 20 Temporal monitoring Temporal Control Flow Monitoring Deadline Supervision Temporal Autosar WMD 21 Alive supervision Temporal Autosar WMD 22 Hearbeat 23 Temporal Data Flow Monitoring Data Timeout Monitor 24 Maximum Age 25 Error Handling Masking Error Filtering 26 Default Value 27 Voting 1oo2 Voter 28 2oo3 Voter 29 Error Correction Error Correction Code Hamming code 30 Reed Solomon Code 31 Convolution Code 32 Reporting (CHROMOSOME Health Monitor) 33 (AUTOSAR_DEM) 34 Recovery Reset Partition Reset 35 Device Reset 36 Degradation

According to an embodiment of the present invention, a two-dimensional table in which each AUTOSAR BSW module ID and 36 SAFE safety mechanisms described above are mapped to each other, on the assumption that they are developed based on the AUTOSAR BSW of each software code module to be analyzed. This may be predefined and stored. For example, the analysis code module may be an AUTOSAR BSW No. If the 123 ADC Driver is used, it may be predefined and stored as being subject to the Device Reset item of the SAFE safety mechanism. In addition, according to one embodiment of the present invention, safety features associated with each of the 36 SAFE safety mechanisms described above, such as defect repair priority, implementation difficulty, input effort time according to implementation difficulty, etc., are also previously defined as separate tables. And may be stored. According to one embodiment of the invention, for example, the defect repair priority of each safety mechanism can be classified into five categories, for example, "very high", "high", "medium", "low", and "very low". Can be. According to one embodiment of the invention, for example, the difficulty of implementing each safety mechanism may be classified into five types, for example, "very difficult", "hard", "medium", "easy", and "very easy". . According to an embodiment of the present invention, the implementation difficulty is information related to the input effort time according to the implementation difficulty, for example, the implementation difficulty "very difficult" is the input effort time 24 hours, the implementation difficulty "difficult" is the input effort time 8 hours, implementation difficulty "medium" can be defined as the input effort time 2 hours, implementation difficulty "easy" means the input effort time 1 hour, implementation difficulty "very easy" can be defined as 30 minutes effort, such as the present invention, thereby It is not limited.

The following table is an exemplary classification table of the above described implementation difficulty, which is merely provided as an example to aid the understanding of the present invention and is not intended to limit the present invention.

Difficulty of implementation Commitment effort (minutes) Very difficult 24 h 00 m difficulty 08 h 00 m middle 02 h 00 m facility 01 h 00 m Very easy 00 h 30 m

For example, the parity checker item of the SAFE safety mechanism may be defined as a "high" level among the five classifications, and the difficulty of implementation may be defined as an "easy" level among the five classifications. Here, the above-mentioned matters regarding the platform information that is the basis of the code module development, and the types and definition methods of the code module safety feature information related thereto are provided only for the purpose of understanding the present invention, and the present invention is limited thereto. It should be known. Those skilled in the art will be able to implement, for example, various modifications of how to relate the platform information on which each code module development is based, and what safety feature information. In addition, even if safety feature information related to platform information, which is the basis of development of each code module, is defined once, it can be changed accordingly if necessary. In addition, with respect to the present embodiment, the code module to be analyzed is described as being developed based on the AUTOSAR BSW, but the present invention is not limited thereto. According to another embodiment of the present invention, the code module to be analyzed may be written based on another standard development platform.

According to an embodiment of the present invention, the risk analysis unit 306 may generate a report on information on whether or not each of the input software code module is dangerous. According to one embodiment of the invention, the risk analysis unit 306, the code module safety feature acquisition unit 308, along with the results of the risk analysis of each code module (that is, True or False value for each code module) You can create a report that contains safety feature information about the code module you have obtained from.

According to an embodiment of the present invention, the safety information of the code module included in the report generated by the risk analysis unit 306 may be, for example, a corresponding safety mechanism name (eg, a parity checker of the SAFE ISO 26262 safety mechanism), Related description (eg, description of the parity checker of the SAFE ISO 26262 safety mechanism), safety category (eg, Error Detection category), priority (eg, "high"). Implementation difficulty (e.g. "easy"), input effort time (e.g. 1 hour), code portion of the corresponding code module, reference (e.g. using the SAFE ISO 26262 safety mechanism, http: // Sample code and links to the description of the safety mechanism in www.safe-project.eu/SAFE-Publications/SAFE_D3.6.b.pdf, ie the relevant sample code provided by the SAFE ISO 26262 safety mechanism or other applicable safety. Related to the mechanism, such as predetermined sample code, etc.) If such safety information is included in the report, the developer / maintenance of the software code which has confirmed this, for example, has analyzed that the code module is dangerous, It is related to the parity checker item in the Error Detection category of the SAFE ISO 26262 safety mechanism. The priority of defect repair is high, the difficulty of implementation is easy, and the input effort time is 1 o'clock. In addition, this information can be compared to corresponding information about software code modules that have been analyzed as dangerous and can be used to make decisions about which software code module to repair first (eg, defect repair). Can be proceeded in order of high priority, low implementation difficulty, low priority, and high implementation difficulty) The safety information is only an example to help understanding of the present invention, and the present invention is limited thereto. No. One of ordinary skill in the art would be able to come up with more other safety mechanism safety information that may be included in the report of the results of the code analysis and provided to the developer / maintenance of the software code. The report may contain some or any other safety information listed above. May be, according to one embodiment of the invention, the safety information for the code module included in the report generated by the risk analysis unit 306, for example, may include a table, types of information are listed in the following table. The following table is only to aid the understanding of the present invention, it should be understood that the present invention is not limited thereto.

Item Explanation Safety Mechanism Name Safety Mechanism Persons Related Description Safety Mechanism Description Remarks Remarks Safety category Indication of the specific safety category to which the safety mechanism belongs Defect repair priority Application priority divided into five
(Very high, high, medium, low, very low) Difficulty of implementation Divided into five difficulty levels
(Very difficult, difficult, medium, easy, very easy) Commitment time Input effort time according to implementation difficulty Code safety part Code safety that can be obtained when applying this Safety Mechanism
E.g. ParityCheck Safety Mechanism: detects whether data is contaminated during data communication or storage Reference Safety Mechanism Reference Code example X checksum for Y bit parity
-----------------------
parity (X, Y) true: false

According to an embodiment of the present invention, the category marker index calculator 310 may calculate the marker indicator for each category of the code module based on the value analyzed by the risk analyzer 306.

According to an embodiment of the present invention, a category indicator is a value representing a risk level for each category of a code module, and may be displayed at 0 to 100 levels. The higher the level of the category marker, the more likely it is to be determined to be safer, and the lower it can be determined to be a code containing risks. According to an embodiment of the present invention, the category marker calculation may be displayed by dividing all safety mechanisms found in the code module into appropriate categories, and may be calculated in consideration of factors such as global indicators, target effort, and code size. According to an embodiment of the present invention, categories of safety mechanisms may be classified into three types, including fault avoidance, error detection, and error handling.

According to an embodiment of the present invention, in order to calculate the category markers, factors such as global indicators for each category, effort cost, code size, risk level of the code module, and the like may be considered.

In an embodiment of the present invention, the global index for each category may refer to the number of safety mechanisms requiring action for each category. If the value of the global indicator for each category is high, the level of the category indicator may be low. If the value of the global indicator for each category is small, the level of the category indicator may be increased. In one embodiment of the invention, the reference value of the global indicator by category is the total number of safety mechanisms.

In an embodiment of the present invention, the effort cost may mean an effort cost (input time) required for improvement according to the global index for each category. If the value of effort cost is high, the level of the category indicator is low, and if the value of effort cost is low, the level of the category indicator can be high. In one embodiment of the present invention, the reference value of effort cost is the effort cost of the safety mechanism.

In the embodiment of the present invention, the code size means the size of the code of the entire software. If the value of the code size is large, the level of the category indicator is low. If the value of the code size is small, the level of the category indicator is high. In one embodiment of the present invention, the reference value of the code size may be calculated by defining a weight reference based on the code amount of the entire code module. The table below is only illustrative of how to calculate the code size, and the invention is not so limited.

Code Count (Lines) <= 2,500 <= 5,000 <= 7,500 <= 10,000 weight 1.3 1.1 0.9 0.7

In the embodiment of the present invention, the risk level of the code module is as described above. If the value of the risk level is large, the level of the category indicator is low, and if the value of the risk level is small, the level of the category indicator can be high. In one embodiment of the present invention, the reference value of the risk level of the code module may be calculated by defining a weighting criterion based on the risk level. The table below is merely illustrative of how the risk level is calculated, and the invention is not so limited.

Risk level A B C D weight 1.3 1.1 0.9 0.7

In one embodiment of the present invention, the category indicator index can be calculated as follows.

Equation 1

Category marker index

E _f : Sum of effort costs of safety mechanisms requiring action

E _t : Sum of effort costs of the entire safety mechanism

W _RL : Risk Level Criteria Weight

W _LOC : Weight based on code amount

Example

According to an embodiment of the present invention, the category marker index may be obtained by applying Equation 1 above.

1. Fault Avoidance Category

The sum of the effort cost of the safety mechanism in the defect avoidance category is 100 hours, the sum of the effort cost of the effort of the safety mechanism requiring action, 80 hours, the code size for the combined avoidance category is approximately 6,000 lines, and the maximum risk level found is C Then, the category marker index is as follows.

Fault Avoidance Category Marker Index

About 16.2 shows that the code for the defect avoidance category is dangerous.

2. Error Detection Category

The sum of the effort cost of the safety mechanism in the error detection category is 100 hours, the sum of the effort cost of the safety mechanism that requires action is 30 hours, the code size for the error detection category is about 3,000 lines, and the maximum risk level found is C, the category marker index is as follows.

Error Detection Category Marker Index

At about 49.5, the code associated with the error detection category can be interpreted as necessary to observe.

3. Error Action Category

The sum of the effort cost of the safety mechanism in the error action category is 100 hours, the sum of the effort cost of the safety mechanism that requires action is 30 hours, the code size for the error action category is approximately 3,000 lines, and the maximum risk level found is A, the category marker index is as follows.

Error Action Category Marker Index

At around 100, the code for the error action category can be interpreted as fairly secure code.

According to the exemplary embodiment of the present invention, the target index simulation unit 312 may simulate an effort cost for satisfying the target index based on the value analyzed by the category marker calculator 310.

According to an embodiment of the present invention, the safety mechanisms that need to be prioritized are sorted, and the sorting criteria are arranged in order of safety mechanisms having a high priority among the safety mechanisms and having a low implementation difficulty. 4 is a graph showing the grouping of the ranking of safety mechanisms according to the relationship between priority and implementation difficulty according to an embodiment of the present invention. As shown in the figure, in order to efficiently achieve the target index, the safety mechanism with low implementation difficulty and high priority may be proposed.

According to embodiments of the present invention, a set of safety mechanisms may be calculated that allow each category marker to achieve a target index. For example, the set of safety mechanisms for each category may calculate the sum of total input effort time and the sum of input effort time for all category targets.

Calculation Example

It is assumed that the code size corresponding to the error detection category is about 3,000 lines, the maximum risk level found is C, and a safety mechanism has been found that requires the measures in the table below.

safety
Mechanism category priority
ranking avatar
difficulty Commitment
Minutes reflection
Whether deduction
Number Parity check Error Detection height facility 60 X 2 Sensor Correlation Error Detection height difficulty 480 O 3 Sensor Rationality Check Error Detection Very high usually 120 O 4 Analytic Redundancy Error Detection height usually 120 O One Logical Control Flow Monitoring Error Detection lowness So
difficulty 1440 X One Data Sequence Monitor Error Detection usually difficulty 480 X 2 Data Timeout Monitoring Error Detection Very high facility 60 X 5 Maximum Age Monitoring Error Detection height difficulty 480 X 3

1. Align safety mechanisms that need action

Except for the safety mechanisms (Sensor Correlation, Sensor Retionality Check, and Analytic Redundancy) that have already been reflected, the table below can be prepared by sorting them in order of safety mechanisms with high priority and satisfying low implementation difficulty.

safety
Mechanism category priority
ranking avatar
difficulty Commitment
Minutes reflection
Whether deduction
Number Data Timeout Monitoring Error Detection Very high facility 60 X 5 Parity check Error Detection height facility 60 X 2 Maximum Age Monitoring Error Detection height difficulty 480 X 3 Data Sequence Monitor Error Detection usually difficulty 480 X 2 Logical Control Flow Monitoring Error Detection lowness So
difficulty 1440 X One

2. Compute the set of safety mechanisms that enable each category marker to achieve the target index.

The current error detection category marker index is about 32.05.

Error Detection Category Marker Index

When the target index value of the error detection category index is 60, if the safety mechanisms for three data timeout monitoring, parity check, and maximum age monitoring are applied, the target error detection category index index is about 61.29.

Target Error Detection Category Marker Index

Thus, the target index can be achieved.

3. Calculate the sum of the input effort times of the set of safety mechanisms for each category.

The effort to put in a set of safety mechanisms requiring the application of the error detection category is 31 hours (1,860 minutes).

4. Calculate the sum of input effort time for all category goals.

Similarly, the sum of input effort time for each category can be obtained. Assuming that only an error detection category exists, the sum of input effort time for each category is 31 hours.

According to an embodiment of the present invention, the target index simulation unit 312 may provide a summary of the simulation results to the user. The table below presents a table that provides a summary of examples applied to calculation examples to a user.

Category Current reliability
Indices Target reliability
Indices Expected Reliability
Indices Expected commitment
Effort cost Fault Avoidance 12.8 - 12.8 - Error Detection 32.05 60 61.29 31h Error Handling 65.2 - 65.2 - sum 36.68 46.43 31h

Finally, the table below presents a list of expected safety mechanisms that need to be applied to satisfy the Category Marker Index, which is finally provided to the user.

Safety
Mechanism category priority
ranking avatar
difficulty Commitment
Minutes reflection
Whether deduction
Number Data Timeout Monitoring Error Detection Very high facility 60 X 5 Parity check Error Detection height facility 60 X 2 Maximum Age Monitoring Error Detection height difficulty 480 X 3

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, such as an EPROM, an EEPROM, a nonvolatile memory such as 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. In addition, 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 variations that fall within the true spirit and scope of the present invention are intended to be covered by the following claims.

302: analysis code information input unit
304: risk data metric measurement unit
306: risk analysis
308: code module safety feature acquisition unit
310: category marker calculation unit
312: target index simulation unit

Claims (10)

A method of simulating a computer-implemented electronic software module based on a standard platform that satisfies a target reliability index.
When the software code module is determined to be dangerous by receiving the software code module and standard platform identification information related to the creation of the software code module, and determining whether the software code module is dangerous by using an analysis machine, Obtaining safety information of the software code module from the safety information is obtained based on the standard platform identification information;
Calculating a category indicator index for each category to which the software code module is classified, wherein the category includes fault avoidance, error detection, and error handling; Contains-and
Receiving a target reliability index and providing a list of expected safety mechanisms that allow each category marker index to achieve the target reliability index, wherein the category marker index is

Are calculated according to
E _f : Sum of effort costs of safety mechanisms requiring action
E _t : Sum of effort costs of the entire safety mechanism
W _RL : Risk Level Criteria Weight
W _LOC : weight based on code _amount-
A method of simulating such that the safety of the electronic software code module, including the target reliability index. The method of claim 1,
Wherein the category marker index is calculated based on the global index for each category, the effort cost, the code size, and the risk level of the code module. The method of claim 1,
The database stores information for mapping the standard platform identification information to one of a plurality of safety mechanisms defined in Safe Automotive soFtware archiTecture (SAFE) ISO 26262,
And the database further stores one or more predefined safety information corresponding to the mapped one safety mechanism to ensure that the safety of the electronic software code module satisfies a target reliability index. The method of claim 3,
At least one predefined safety information corresponding to the mapped one safety mechanism is updatable, such that the safety of the electronic software code module satisfies a target reliability index. The method of claim 3,
The one or more safety information predefined corresponding to the mapped one safety mechanism includes at least one of a priority of defect repair, difficulty of implementation, and input effort time. How to simulate to satisfy. The method of claim 5,
Wherein the priority of the defect repair and the difficulty of implementation correspond to each one of a plurality of predetermined levels, wherein the safety of the electronic software code module satisfies a target reliability index. The method of claim 3,
A plurality of safety mechanisms defined in SAFE ISO 26262 are classified into a predetermined number of categories, and the mapped one safety mechanism belongs to one category of the predetermined number of categories. How to simulate to satisfy the exponent. The method of claim 7, wherein
The method is
Generating a report of the calculation of the set of safety mechanisms;
The result report may include a name of the mapped one safety mechanism, a description of the mapped one safety mechanism, the category of the mapped one safety mechanism, and the priority of defect repair of the mapped one safety mechanism. And at least one of an implementation difficulty of the mapped one safety mechanism and an input effort time of the mapped one safety mechanism. A computer device, the computer device operable to carry out the method of claim 1. 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