CN108255728B

CN108255728B - Method and device for identifying failure mode of software

Info

Publication number: CN108255728B
Application number: CN201810050215.2A
Authority: CN
Inventors: 李冬; 刘畅; 刘梦玥; 刘奕宏; 邹臻; 杨春晖; 王强
Original assignee: China Electronic Product Reliability and Environmental Testing Research Institute
Current assignee: China Electronic Product Reliability and Environmental Testing Research Institute
Priority date: 2018-01-18
Filing date: 2018-01-18
Publication date: 2021-03-09
Anticipated expiration: 2038-01-18
Also published as: CN108255728A

Abstract

The invention discloses a method and a device for identifying a failure mode of software, which relate to the technical field of Internet, and comprise the following steps: dividing a preset demand model for constructing software into a software external interface model, a software function model, a software working state model and a software system dependency relationship model; analyzing the independent function failure mode of the software, the function combination failure mode of the software and the state transition failure mode of the software respectively based on the models; the software failure analysis method fully reflects software working state conversion and software failure caused by combination of a plurality of functions, can analyze software failure modes in an all-around manner, and has the advantages of universality, easiness in popularization and reproducibility, so that the real reason and potential threat of software failure are found in the software development process, the improvement of the safety design level in the software development stage is effectively promoted, the pertinence and the effectiveness of corrective measures are enhanced, the safety of software products is improved, and the equipment damage and the software full-life cycle cost caused by software failure are reduced.

Description

Method and device for identifying failure mode of software

Technical Field

The invention relates to the technical field of internet, in particular to a method and a device for identifying a failure mode of software.

Background

Today the system of the new generation of military equipment has become a typical software intensive system with configured software having a significant impact on security and task completion. At the same time, there are increasing system security issues due to software failures, and it is statistical that software-induced failures in modern military equipment account for over 70% of the total number of failures. Once the safety-critical software fails or fails, the task fails if the safety-critical software fails, and equipment damage or even casualties occur if the safety-critical software fails or fails.

Therefore, in the software development process of military equipment, the software security has been taken as a key concern, and a series of security standards are issued, which specify security work to be performed at each stage in the equipment life cycle, i.e., the Analysis work of developing FMEA (Failure Mode and Effect Analysis).

In the conventional technology, a software system hierarchical structure and a dependency relationship model are established, and a specific software failure mode of a target software system is analyzed, specifically comprising the following steps: extracting failure modes based on the functional description of the software modules, and extracting failure modes based on the data flow information among the modules; extracting failure modes based on data exchange between the target software system and an external data source; failure modes are extracted based on possible operational results of the module. Because the software failure mode analysis is carried out on the basis of the hierarchical structure and the dependency relationship, the conversion of the software working state is not reflected, the failure mode aiming at the software state cannot be obtained, and the software failure mode caused by the combination of a plurality of functions is not considered, so that the software failure mode is not comprehensively analyzed, the real reason of the software failure cannot be found, and the task failure, even the equipment damage and even the casualties are caused.

Disclosure of Invention

Therefore, the invention provides a method and a device for identifying a software failure mode, which are needed to solve the problems that the software failure mode is incomplete and the failure reason cannot be found.

The embodiment of the invention provides a method for identifying a failure mode of software, which comprises the following steps:

dividing a preset demand model for constructing software to obtain a software external interface model, a software function model, a software working state model and a software system dependency relationship model;

analyzing an independent function failure mode of the software based on the software external interface model and the software functional model to obtain an analysis result of the independent function failure mode; wherein the independent functional failure modes of the software comprise: a function input failure mode, a function processing process failure mode and a function output failure mode;

analyzing a function combination failure mode of the software based on the software function model and the software system dependency relationship model to obtain an analysis result of the function combination failure mode;

analyzing a state transition failure mode of the software based on the software working state model and the software system dependency relationship model to obtain an analysis result of the state transition failure mode;

and identifying the reason of the software failure according to the analysis result of the independent function failure mode, the analysis result of the function combination failure mode and the analysis result of the state transition failure mode.

Accordingly, an embodiment of the present invention provides an apparatus for identifying a failure mode of software, including:

the software system comprises a partitioning module, a software system dependency relationship model and a software external interface model, wherein the partitioning module is used for partitioning a preset demand model for constructing software to obtain the software external interface model, the software function model, the software working state model and the software system dependency relationship model;

the independent function analysis module is used for analyzing an independent function failure mode of the software based on the software external interface model and the software functional model to obtain an analysis result of the independent function failure mode; wherein the independent functional failure modes of the software comprise: a function input failure mode, a function processing process failure mode and a function output failure mode;

the function combination analysis module is used for analyzing the function combination failure mode of the software based on the software function model and the software system dependency relationship model to obtain the analysis result of the function combination failure mode;

the state transition analysis module is used for analyzing the state transition failure mode of the software based on the software working state model and the software system dependency relationship model to obtain an analysis result of the state transition failure mode;

and the software failure reason identification module is used for identifying the reason of the software failure according to the analysis result of the independent function failure mode, the analysis result of the function combination failure mode and the analysis result of the state transition failure mode.

Accordingly, an embodiment of the invention provides a readable storage medium having stored thereon a computer program for executing by a processor the steps of the method according to any one of the above.

Accordingly, embodiments of the present invention provide a computer device, comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the steps of the method as described in any one of the above when executing the program.

One of the above technical solutions has the following advantages and beneficial effects:

according to the embodiments of the method and the device for identifying the failure mode of the software, the preset demand model is divided into a software external interface model, a software function model, a software working state model and a software system dependency relationship model; and analyzing an independent function failure mode of the software, a function combination failure mode of the software and a state transition failure mode of the software based on a software external interface model, a software function model, a software working state model and a software system dependency relationship model.

Therefore, the method fully embodies the software failure caused by the conversion of the software working state and the combination of a plurality of functions, can analyze the software failure mode in all directions, and has the advantages of strong universality, easy popularization and reproducibility, thereby discovering the real reason and the potential threat of the software failure in the software development process, effectively promoting the improvement of the safety design level in the software development stage, enhancing the pertinence and the effectiveness of the corrective measures, improving the safety of software products, and reducing the equipment damage and the software full life cycle cost caused by the software failure.

Drawings

FIG. 1 is a first flowchart of a method for identifying failure modes of software according to an embodiment of the present invention;

FIG. 2 is a second flowchart of a method for identifying failure modes of software according to an embodiment of the present invention;

FIG. 3 is a third flowchart of a method for identifying failure modes of software according to an embodiment of the present invention;

FIG. 4 is a fourth flowchart of a method for identifying failure modes of software according to an embodiment of the present invention;

FIG. 5 is a fifth flowchart of a method for identifying failure modes of software according to an embodiment of the present invention;

FIG. 6 is a sixth flowchart of a method for identifying failure modes of software according to an embodiment of the present invention;

FIG. 7 is a seventh flowchart of a method for identifying failure modes of software according to an embodiment of the present invention;

FIG. 8 is a diagram illustrating a software system hierarchy and a dependency model in the prior art;

fig. 9 is a schematic structural diagram of a software failure mode and impact analysis apparatus according to an embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention more clearly apparent, the following describes in detail the method and apparatus for identifying a failure mode of software according to the present invention by using an embodiment and with reference to the accompanying drawings.

It is to be understood that, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

The embodiment of the invention provides a method for identifying a failure mode of software, which comprises the following steps as shown in figure 1:

s110: and dividing a preset demand model for constructing software to obtain a software external interface model, a software function model, a software working state model and a software system dependency relationship model.

Where a requirement refers to a condition or capability that a system or system component must meet or process in order to meet the requirements of contract data, standard data, specification data, or other mandatory document data.

The requirement specification refers to document data that specifies requirements of a system or a component, such as functional requirements, performance requirements, or interface requirements.

The requirement model is a technical method for describing software requirement specifications by a semi-formal graphic language, a formal mathematical language or a computer language; compared with the software requirement described by natural language, the method has the advantages of more accuracy, objectivity and automation.

In this embodiment, a model-driven military equipment software failure mode identification technology is provided to ensure that increasingly complex software failure modes such as interface fault combination, multi-functional interaction, state scene switching, and the like are sufficiently identified and analyzed.

Specifically, when a user directly inputs a software identification and analysis instruction, or sets a corresponding trigger condition, and when the trigger condition is met, the software identification and analysis instruction is judged to be effective; and based on a preset demand model, namely a system demand model of 'software external interface-software function-software working state', dividing the preset demand model for constructing software into a software external interface model, a software function model, a software working state model and a software system dependency relationship model, carrying out software failure mode identification, and obtaining the reason of software failure.

Specifically, the software failure mode includes an independent function failure mode of the software, a function combination failure mode of the software and a state transition failure mode of the software; accordingly, in the subsequent process, according to the divided submodels, the recognition analysis of the independent function failure mode, the recognition analysis of the function combination failure mode and the recognition analysis of the state transition failure mode can be realized.

It should be noted that a software failure means that a software system or component cannot perform its required functions according to specified performance requirements.

It should be noted that the software failure mode refers to a representation of the physical or functional nature of the software failure; failure modes such as software may be characterized by slow operation, incorrect output, or complete termination of execution.

S120: analyzing the independent function failure mode of the software based on the software external interface model and the software functional model to obtain an analysis result of the independent function failure mode; wherein the independent functional failure modes of the software comprise: a functional input failure mode, a functional processing procedure failure mode and a functional output failure mode.

Specifically, the Software function is a complete expression of a Software CSCI (Computer Software Configuration Item) capability Item, and the Software basic behavior elements including "input interface-function processing-output interface" are the foundation for performing security analysis.

Therefore, in this embodiment, based on the divided software external interface model and software functional model, the independent functional failure mode analysis of the software is performed, where the independent functional failure mode of the software includes: analyzing a function input failure mode, analyzing a function processing process failure mode, analyzing a function output failure mode, and obtaining a corresponding analysis result.

It should be noted that the execution sequence of the function input failure mode analysis, the function processing failure mode analysis, and the function output failure mode analysis is not limited.

S130: and analyzing the function combination failure mode of the software based on the software function model and the software system dependency relationship model to obtain an analysis result of the function combination failure mode.

In this embodiment, since the software functions have a complex cross-linking relationship, and the software function combination may have a failure condition, the failure mode of the software function combination is analyzed based on the divided software function model and the software system dependency relationship model, and a corresponding analysis result is obtained.

S140: and analyzing the state transition failure mode of the software based on the software working state model and the software system dependency relationship model to obtain an analysis result of the state transition failure mode.

In this embodiment, since software has a changeable state scene, there is a case of software failure in a scene conversion process of a software operating state, a state transition failure mode of the software is analyzed based on a software operating state model and a software system dependency relationship model, and a corresponding analysis result is obtained.

S150: and identifying the reason of the software failure according to the analysis result of the independent function failure mode, the analysis result of the function combination failure mode and the analysis result of the state transition failure mode.

In the embodiment, the reason causing the software failure can be quickly and accurately obtained by analyzing the independent function failure mode, the function combination failure mode and the state transition failure mode and obtaining corresponding analysis results, so that the failure mode analysis of the software is completed, and the related analysis results and the failure reasons are returned to a user for reference in a data form.

It should be noted that, by analyzing the independent function failure mode of the software, the function combination failure mode of the software, and the state transition failure mode of the software respectively in step S120, step S130, and step S140, it can be seen that the execution sequence of step S120, step S130, and step S140 is not limited, and therefore, improvements (such as synchronous execution or sequential execution) made on the execution sequence of step S120, step S130, and step S140 all belong to the protection scope of the present invention.

It should be understood that the analysis method provided by the invention can be applied to relevant software in the field of military equipment, and can also be applied to the field of other software-intensive systems, such as Windows operating systems and the like.

In the traditional technology, a software system hierarchical structure and a dependency relationship model are established to analyze a specific software failure mode of a target software system, and because the software failure mode analysis is carried out on the basis of the hierarchical structure and the dependency relationship, the conversion of a software working state is not reflected, the failure mode aiming at the software state cannot be obtained, and meanwhile, the software failure mode caused by the combination of a plurality of functions is not considered, so that the software failure mode is not comprehensively analyzed, the real reason of the software failure cannot be found, and the task failure, even the equipment damage and even the casualties are caused.

In the embodiment, the software failure mode analysis is performed based on the preset requirement model, so that the software failure caused by the conversion of the software working state and the combination of a plurality of functions is fully reflected, the software failure mode can be analyzed in all directions, and the method has the advantages of strong universality, easiness in popularization and reproducibility, so that research and development personnel can be helped to find the real reason and the potential threat of the software failure in the software development process, the improvement of the safety design level in the software development stage is effectively promoted, the pertinence and the effectiveness of corrective measures are enhanced, the safety of software products is improved, and the equipment damage and the software full life cycle cost caused by the software failure are reduced.

In one embodiment, as shown in FIG. 2, the step of analyzing the functional input failure mode comprises:

s210: and analyzing whether the input data model elements of each single input data with independent functions are abnormal or not based on the input data model elements for constructing the software external interface model.

In this embodiment, the input data model elements include a data class, a time class, a communication fault class, a fault handling class, a redundancy class, and a dependency class of the input data, and when any one of the model elements is abnormal, the software may be disabled, so that whether the input data model element is abnormal or not is analyzed.

Specifically, the data model elements include value ranges, boundaries, precision and change rates, and the data abnormal conditions which may occur are identified according to the interface type, data unit, data value range, data precision and data source of the current input data; for example, the following steps are carried out: the data type of the current input data is illegal, the unit conversion of the current input data is wrong, the value of the current input data exceeds the effective range of the value range or the precision of the current input data is poor.

Specifically, the time model elements include a value time limit, a time sequence and a period, and the time processing abnormal conditions which may occur are identified aiming at the time processing of the current input data, such as the time sequence, the period or the value time; for example, the following steps are carried out: the current input data is not updated for a long time or the value taking period of the current input data is illegal.

Specifically, the communication fault model elements include a data frame format, a communication line or a communication rate, and identify a communication abnormal condition which may occur aiming at a communication protocol of current input data; for example, the following steps are carried out: the data frame of the current input data is received incompletely or the communication line of the current input data is interrupted.

Specifically, the fault handling model elements include fault diagnosis, processing and resetting methods and initial values and safety value settings, and fault handling abnormal conditions which may occur are identified aiming at fault handling of current input data, such as fault diagnosis, fault handling, fault recovery or default value design; for example, the following steps are carried out: the current input data is not subjected to fault diagnosis, other functions are disabled due to fault processing countermeasures of the current input data, the fault of the current input data cannot be reset, or the fault default value of the current input data is unreasonable.

Specifically, the redundancy model elements comprise redundancy voting and redundancy judgment methods, and the redundancy processing abnormal conditions which may occur are identified according to the redundancy of the current input data, such as redundancy design, redundancy voting and redundancy switching; for example, the following steps are carried out: the redundancy of the current input data is totally invalid, the redundancy voting threshold of the current input data is unreasonable or the redundancy switching of the current input data fails.

Specifically, the dependency relationship type model elements are dependency relationships of external interfaces of different types of software, and possible abnormal conditions are identified according to a data constraint relationship, a time constraint relationship and a logic constraint relationship of current input data.

S220: after analyzing the input data model elements, arranging and combining each single input data to obtain a plurality of input data combination modes, and analyzing whether each input data combination mode is abnormal or not.

In this embodiment, on the basis of the input data model element analysis, a software failure condition may occur after a plurality of single input data are combined, at this time, each single input data is arranged and combined to obtain a plurality of input data combination modes, and for the input data combination mode, the arrangement and combination conditions of normal/failure of the plurality of data are analyzed to identify a possible combination failure.

In addition, especially when a plurality of single input data have a dependency relationship of a data constraint, a time constraint and a logic constraint, it is also necessary to analyze whether there is an abnormal situation that violates the above dependency relationship.

S230: and after analyzing all input data model elements and input data combination modes, obtaining an analysis result of the functional input failure mode.

In this embodiment, it is determined whether one-hundred-percent coverage recognition analysis is performed on the input data model elements and the input data combination modes, that is, all the input data model elements and the input data combination modes are recognized and analyzed, and if yes, an analysis result of the functional input failure mode is obtained.

It should be understood that, when all the input data model elements and the input data combination modes are not identified and analyzed, the step S210 is returned until all the identification and analysis of the input data model elements and the input data combination modes are completed.

It should be noted that the combination of the input data model elements and the input data includes, but is not limited to, the above examples, and other examples are within the scope of the present invention without departing from the spirit of the present invention.

As described above, in the embodiment, the input data model element and the input data combination mode are fully considered, the functional input failure mode is analyzed, and the potential software defects can be more effectively exposed, so that the safety of software products is really improved, the testing and maintenance work in the later stage of software development is reduced, and the development cost is reduced.

In one embodiment, as shown in fig. 3, the step of analyzing the failure mode of the functional process comprises:

s310: and analyzing whether each subprocess model element is abnormal or not based on the subprocess model elements for constructing the software function model.

Specifically, the sub-process model elements comprise a mapping relation class and a sub-process sequence class, and when any one of the above model elements is abnormal, the software can be failed, so that whether the sub-process model elements are abnormal or not is analyzed.

Specifically, the abnormal conditions of the mapping relation model elements include whether the mapping relation between the software function input and output and the function processing process is sufficiently accurate, whether the input data has corresponding output data and whether software failure is caused, and the possible abnormal conditions are identified according to the relevant input data and output data of the current function processing sub-process.

Specifically, the abnormal conditions of the sub-process sequence model elements include unreasonable judgment nodes, lack of logic branches or repeated or contradictory processing logics, and the abnormal conditions which may occur are identified aiming at the sub-process description, judgment nodes or sub-process sequence elements of the current function processing sub-process; for example, the following steps are carried out: the logic judgment condition of the current function processing subprocess omits the input data or the logic branches of the current function processing subprocess sequence are non-orthogonal.

S320: and analyzing various processing mode model elements based on the processing mode model elements for constructing the software function model.

In this embodiment, the processing mode model elements include a data processing class, a data processing performance index class, a time processing performance index class, a fault processing class, and a redundancy processing class, and when any one of the above model elements is abnormal, it may cause software failure, so that whether the processing mode model element is abnormal or not is analyzed.

Specifically, the data processing model elements include data values, time sequences and precision, and identify possible abnormal conditions aiming at data processing of a current function processing mode, such as data acquisition, data calculation, logic judgment and fault tolerance processing; for example, the following steps are carried out: the resolving process of the current function is divided by 0 or the current function does not judge whether the data source is credible.

Specifically, the abnormal conditions of the data processing performance index model elements include performance reduction, precision loss and processing deviation, and the abnormal conditions which may occur are identified aiming at the data processing of the current function processing mode, such as data acquisition, data resolving, logic judgment and fault tolerance processing; for example, the following steps are carried out: the current function collects outdated data or the resolving process precision of the current function is out of tolerance.

Specifically, the abnormal conditions of the time processing type model elements include time sequence errors, execution overtime or repeated execution, and the abnormal conditions which may occur are identified aiming at the time processing of the current function processing mode, such as time sequence processing, cycle processing, time limit judgment or abnormal interruption; for example, the following steps are carried out: the execution process of the current function is abnormally interrupted or the execution period of the current function is unreasonable.

Specifically, the abnormal conditions of the time processing performance index model elements include performance reduction, performance delay, performance advance and performance processing deviation, and the possible abnormal conditions are identified aiming at the time processing of the current function processing mode, such as time sequence processing, periodic processing, time limit judgment or abnormal interruption; for example, the following steps are carried out: the execution time of the current function is overlong or the starting execution time of the current function has delay.

Specifically, the abnormal conditions of the fault handling type model elements include that fault diagnosis, fault diagnosis false alarm or false alarm is not performed, and the possible abnormal conditions are identified aiming at fault handling of the current function handling mode, such as fault diagnosis, fault recovery, fault reporting or fault alarm; for example, the following steps are carried out: and the current functional fault diagnosis false alarm or the current functional fault diagnosis is not reported.

Specifically, the redundancy processing type model elements comprise redundancy switching and a redundancy strategy, and the possible abnormal conditions are identified aiming at the redundancy processing of the current function processing mode, such as redundancy design, redundancy voting or redundancy switching; for example, the following steps are carried out: the redundancy switching of the current function fails or the redundancy switching process of the current function interrupts the execution of the function.

S330: and after analyzing all the sub-process model elements and the processing mode model elements, obtaining an analysis result of the functional processing process failure mode.

In this embodiment, it is determined whether one-hundred-percent coverage recognition analysis is performed on the subprocess model elements and the processing mode model elements, that is, all the subprocess model elements and the processing mode model elements are analyzed, and if yes, an analysis result of the functional processing process failure mode is obtained.

It should be understood that when all the sub-process model elements and the processing manner model elements are not analyzed, the step S310 is returned until the recognition analysis of all the sub-process model elements and the processing manner model elements is completed.

It should be noted that the execution order of step S310 and step S320 is not limited.

As described above, in the embodiment, the sub-process model elements and the processing mode model elements are fully considered, the processing process failure mode is analyzed, potential defects existing in the software system are effectively discovered and corrected, the safety design level of the software system is improved, the later-stage software maintenance cost is reduced, and important economic benefits and social benefits are achieved.

In one embodiment, as shown in fig. 4, the step of analyzing the functional output failure mode includes:

s410: and analyzing whether the output data model elements of each single output data are abnormal or not based on the output data model elements for constructing the software external interface model.

Specifically, the output data model element includes a data class, a time class, a communication fault class, a fault handling class, a redundancy class and a dependency relation class of the output data, and when any one of the above model elements is abnormal, the software may be failed, so that whether the output data model element is abnormal or not is analyzed.

Specifically, the data model elements of the output data include value ranges, boundaries, precision or change rates, and the data type, data unit, data value range, data precision or data purpose of the current output data is aimed at to identify the possible abnormal conditions of the data; for example, the following steps are carried out: the positive and negative of the current output data are reversed or the valid data are repeatedly output.

Specifically, the time model elements include a value time limit, a time sequence and a period, and identify possible abnormal conditions of time processing class aiming at the time processing of the current output data, such as the time sequence, the period or the output moment; for example, the following steps are carried out: the output period of the current output data is unreasonable or the duration of the current output data kept output is too short.

Specifically, the communication fault model elements include a data frame format, a communication line and a communication rate, and identify a communication abnormal condition which may occur aiming at a communication protocol of current output data; for example, the following steps are carried out: the size of the output buffer area of the current output data is unreasonable or the communication address of the current output data is invalid.

Specifically, the abnormal conditions of the fault handling type model elements include fault diagnosis, handling of reset method abnormality and unreasonable setting of initial value safety values, and the fault handling type abnormal conditions which may occur are identified aiming at fault handling of current output data, such as fault diagnosis, fault handling, fault recovery or default value design; for example, the following steps are carried out: the current output data is not subjected to limit output value protection or whether the output data range exceeds the limit is not judged.

Specifically, the redundancy model elements comprise a redundancy voting method and a redundancy judgment method, and the redundancy processing abnormal conditions which may occur are identified according to the redundancy of the current output data, such as redundancy design, redundancy voting or redundancy switching; for example, the following steps are carried out: the redundancy of the current output data is totally invalid or the redundancy switching of the current output data fails.

Specifically, the abnormal conditions of the dependency relationship model elements include whether the dependency relationships of external interfaces of different types of software are reasonable and accurate and whether the software fails, and the abnormal conditions which may occur are identified according to the data constraint relationship, the time constraint relationship and the logic constraint relationship of the current output data.

S420: after analyzing whether the output data model elements are abnormal or not, arranging and combining the single output data to obtain a plurality of combined output data, and analyzing whether the combined output data are abnormal or not.

In this embodiment, on the basis of the element analysis of the input data model, a software failure condition may occur after a plurality of single input data are combined, at this time, each single input data is arranged and combined to obtain a plurality of input data combination modes, and for the output data combination mode, the arrangement and combination conditions of normal/failure of the plurality of data are analyzed to identify a possible combination failure.

In addition, especially when a plurality of single output data have dependency relationships such as data constraint, time constraint, logic constraint, and the like, it is necessary to analyze whether there is an abnormal situation that violates the dependency relationships.

S430: and after analyzing all output data model elements and output data combination modes, obtaining an analysis result of the functional output failure mode.

In this embodiment, it is determined whether one hundred percent coverage recognition analysis is performed on the output data model elements and the output data combination modes, that is, all the output data model elements and the output data combination modes are recognized and analyzed, and if yes, the function outputs the analysis result of the failure mode.

It should be understood that, when all the output data model elements and the output data combination modes are not identified and analyzed, the step S410 is returned until all the identification and analysis of the output data model elements and the output data combination modes are completed.

As described above, in this embodiment, a combination mode of the output data model element and the output data is fully considered, and the functional output failure mode is analyzed, so that the improvement of the safety design level in the software development stage can be effectively promoted, the pertinence and the effectiveness of the corrective measure are enhanced, and the improvement of the software safety is realized.

In one embodiment, as shown in fig. 5, the step of analyzing the failure mode of the functional combination of the software comprises:

s510: and analyzing whether each sub-function-sub-function combined model element is abnormal or not based on the sub-function-sub-function combined model element for constructing the software function model.

Specifically, the sub-function-sub-function combination model element includes the dependency and hierarchy of the combination between sub-functions, so the ability of the software function combination to coordinate the completion of tasks, or whether the function combination is correct and effective under abnormal conditions or extreme conditions and whether the software fails or not is analyzed.

Specifically, the conditions of the permutation and combination of the normal/failure of a plurality of functions are analyzed according to the results, and the possible failure of the function combination is identified; for example, the following steps are carried out: the father function contains 3 child kinetic energies, and when 2 of the child kinetic energies fail, the father function cannot work normally.

Specifically, the dependency relationship among a plurality of functions needs to be analyzed, and whether a fault which violates the dependency relationship of the functions exists or not is determined; for example, the following steps are carried out: the execution condition of the parent function does not fully contain the execution condition of the child function.

S520: and analyzing whether each function combination dependency relationship model element is abnormal or not based on the function combination dependency relationship model element for constructing the software system dependency relationship model.

Specifically, the functional combination dependency model elements include a data failure class, a timing failure class and a logic failure class of the software functional combination, and when any one of the model elements is abnormal, the software may be failed, so that whether the functional combination dependency model element is abnormal or not is analyzed.

Specifically, the data failure model elements include data interaction and data input and output among functions, and identify possible abnormal conditions aiming at data constraint relations of current function combinations, such as addition, subtraction or numerical comparison; for example, the following steps are carried out: and the input and output data between multiple functions have abnormal values.

Specifically, the time sequence failure model elements include multi-function concurrent execution, multi-function sequential execution and execution duration, and identify possible abnormal situations for the time constraint relationship of the current function combination, such as sequential execution or concurrent execution; for example, the following steps are carried out: functionality is blocked for long periods by high priority functionality.

Specifically, the abnormal condition of the logic failure type model element includes that processing logic repetition and mutual exclusion function are executed simultaneously, and the abnormal condition which may occur is identified according to the logic constraint relation of the current function combination, such as simultaneous validity, simultaneous invalidity or negation; for example, the following steps are carried out: the processing logic of a function is repeated with other functions.

S530: and after analyzing all the sub-function-sub-function model elements and the function combination dependency relationship model elements, obtaining an analysis result of the function combination failure mode.

In this embodiment, it is determined whether to perform one hundred percent coverage identification analysis on the sub-function-sub-function model elements and the function combination dependency relationship model elements, that is, to identify and analyze all the sub-function-sub-function model elements and the function combination dependency relationship model elements, and if yes, an analysis result of the function combination failure mode is obtained.

It should be understood that, when all the sub-function-sub-function model elements and the function combination dependency relationship model elements are not identified and analyzed, the step S510 is returned until the identification and analysis of all the sub-function-sub-function model elements and the function combination dependency relationship model elements are completed.

It should be noted that the execution order of step S510 and step S520 is not limited.

As described above, in this embodiment, the sub-function-sub-function model element and the function combination dependency relationship model element, that is, the functional characteristics required by the software system, are fully considered to analyze the software function combination failure mode, so as to help the research and development personnel to find the potential software failure in the early stage of software development and design, and effectively promote the improvement of the security design level in the software development stage, thereby greatly reducing the software life cycle cost.

In one embodiment, as shown in fig. 6, the step of analyzing the state transition failure mode of the software comprises:

s610: and analyzing whether each working state model element is abnormal or not based on the working state model element for constructing the software working state model.

Specifically, the working state model element includes a consistency class and a function class, and when any one of the above model elements is abnormal, the software may be disabled, and therefore, whether the working state model element is abnormal or not is analyzed.

Specifically, the consistency model element is consistency between working states of the software equipment system, and identifies possible abnormal conditions aiming at the working state division or state description of the current working state; for example, the following steps are carried out: the entering condition of the current working state is the same as that of other working states, and different working states use the same data to judge conditions or unreasonable state division.

Specifically, the abnormal condition of the function model element includes whether each function in the software working state is abnormal, whether the function causes the working state to be abnormal or whether the software fails, and the abnormal condition which may occur is identified according to the function which needs to be executed or not in the current working state; for example, the following steps are carried out: the function execution error in the operating state or the function execution does not take into account the operating state.

S620: and analyzing whether each state transition path model element is abnormal or not based on the state transition path model elements for constructing the software working state model and the software system dependency relationship model.

Specifically, the state transition path model element includes an interface data class, a transition condition class and a transition path class, and when any one of the above model elements is abnormal, the software may be failed, and therefore, whether the state transition path model element is abnormal or not is analyzed.

Specifically, the abnormal condition of the interface data model element includes each software interface data in the state transition condition, whether the state transition is abnormal or whether the software is invalid, and the abnormal condition which may occur is identified for the software interface data element corresponding to the current state transition condition; for example, the following steps are carried out: the transition conditions of different states are simultaneously met or the transition conditions are abnormally met in the state execution process.

Specifically, the abnormal condition of the transition condition type model element includes whether the state transition condition is sufficiently accurate or whether the software fails, and the abnormal condition which may occur is identified according to the current state transition condition, such as an entry condition, a transition condition or an exit condition; for example, the following steps are carried out: the state transition condition is satisfied but the working state is not entered or the working state cannot exit.

Specifically, the transition path type model elements include a state transition execution process, a potential path and an error path, and identify possible abnormal conditions aiming at a current state scene, such as an initial state, a working state, a state transition condition or an ending state; for example, the following steps are carried out: the function execution condition during the state transition changes or the function output during the state transition conflicts.

S630: and after analyzing all the working state model elements and the state transition path model elements, obtaining an analysis result of the state transition failure mode.

In this embodiment, it is determined whether one hundred percent coverage recognition analysis is performed on the operating state model elements and the state transition path model elements, that is, all the operating state model elements and the state transition path model elements are recognized and analyzed, and if yes, an analysis result of the state transition failure mode is obtained.

It should be understood that, when all the working state model elements and state transition path model elements are not identified and analyzed, the step S610 is returned to until the identification and analysis of all the working state model elements and state transition path model elements are completed.

It should be noted that the execution order of step S610 and step S620 is not limited.

As described above, in this embodiment, the operating state model elements and the state transition path model elements, that is, the state characteristics of the software system requirements, are fully considered to analyze the state transition failure mode of the software, so that the potential software defects can be more effectively exposed, the safety of the software product is really improved, the software life cycle cost is greatly reduced, and the software state transition failure mode analysis method can be applied to airborne, vehicle-mounted, ship-based, ground and other military equipment.

In one embodiment, as shown in fig. 7, before the step of dividing the preset requirement model of the software, the method further includes establishing the preset requirement model; the step of establishing the preset demand model comprises the following steps:

s710: and establishing a software external interface model meeting the modeling basis and requirements of the software external interface.

Specifically, modeling bases and requirements of the software external interface are embodied in a software object, an external cross-linking device, an external interface entity and an external input and output data element, and the modeling bases and requirements are used for establishing a software system external interface model in the form of characters, diagrams and formal languages.

In one embodiment, the step of modeling the external interface of the software system (not shown in the figure) comprises:

step S710 a: the software object is determined, dividing the inner and outer boundaries.

In the embodiment, a software configuration item or system for modeling is determined, and a unique name or identification of a software object is determined according to software requirement specification; and dividing the internal and external boundaries of the software/system according to the modeling object, wherein the internal boundary distinguishes different software configuration items deployed in one military equipment software system, and the external boundary distinguishes different military equipment software systems.

Step S710 b: an external crosslinking device is determined.

In this embodiment, according to the specification of the system/subsystem, the design specification of the system/subsystem, etc., various external cross-linking devices such as sensors, hardware and other onboard software and hardware systems with the software object are determined, and the unique name or identification of the external device is determined.

Step S710 c: determining external interface entities and external input output data elements

In the embodiment, according to the software requirement specification and the software interface control file (ICD), all external interface entities of the software object are specified, and the type of each interface entity is determined.

In addition, the input or output direction of the interface data element is determined according to the communication direction of the data interaction between the interface entity and the software object. And determining the modeling content of the external input and output data element according to the software requirement specification and a software interface control file (ICD), wherein the modeling content comprises a name, an interface type, a numerical value/value range, a communication format, time, a period, fault processing, redundancy design, source equipment and target equipment.

The name is a unique name or identification for describing the external input and output data element of the software; the interface type is an interface type corresponding to the external input and output data element of the description software; the value/value domain describes various possible values of the data element if the external input and output data element of the software is discrete data, and describes an effective value interval of the data element if the external input and output data element of the software is continuous data.

The communication format is a communication protocol format for describing a software external input and output data frame, such as the design of a frame header, a data bit, a status bit or a check bit; time is time information or duration information describing the value of external input and output data of the software; the period is input period information describing external input and output data of the software.

The fault processing is a diagnosis strategy, a processing strategy, a recovery strategy or a default value for describing the external input and output data fault (such as an extreme value fault, a slope fault and a jump fault) of the software; the redundancy design is a redundancy design (such as dual redundancy or quad redundancy) for describing external input and output data of the software, a redundancy voting method and a switching strategy; the source equipment is the source equipment corresponding to the external input data of the description software and is information from the external cross-linking equipment; the target equipment is the target equipment corresponding to the external output data of the description software and is information from the external cross-linking equipment.

Step S710 d: and the modeling process of the software external interface model completes the check.

Specifically, whether all model elements of the external software cross-linking equipment and the input/output interface reach 100% coverage or not is checked, the requirement of the external software interface reaches 100% coverage, and if yes, the modeling process of the external software interface is completed; if not, the process returns to step S710c, and the above steps are repeated.

S720: and introducing a software external interface model, and establishing a software function model meeting the modeling basis and requirements of software functions.

In this embodiment, the modeling basis and requirement of the software function are embodied in the function object and boundary, the function input/output data, the external interface model of the software system, the function processing subprocess, the subprocess processing mode and the set-up subprocess sequence, and the modeling basis and requirement are used to set up the software function model in the form of characters, diagrams and formal languages.

In one embodiment, the step of building a functional model of the software (not shown in the figures) comprises:

step S720 a: functional objects and boundaries and functional input/output data are specified.

In the embodiment, a unique name or an identification of a software function is determined according to the software requirement specification 3.2CSCI capacity requirement; and judging whether the part which has the capability overlapping with other functions exists, determining the boundary of the software function, and distinguishing the software function from other software functions.

In addition, according to the corresponding subsection of the software requirement specification 3.2CSCI capability requirement, all input/output data related in the function operation process are determined; the external interface data element directly references the software external interface model.

Step S720 b: the software system external interface model is invoked.

In this embodiment, the external interface data elements in the functional input/output data are located in the software external interface model, and directly refer to the corresponding interface data element information in the model, such as name, value/value range, communication format, time, period, fault handling, redundancy design, source device, and destination device.

Step S720 c: the functional processing sub-process is divided.

In this embodiment, the process of the function object is divided into indivisible sub-processes, and the modeling content of the sub-processes includes: process name, process description and decision node.

Wherein, the process name is the name of the function processing subprocess; a process is described as describing the behavior of processing specific functional input/output data; the decision node is a logic condition describing a decision processing process and belongs to a special sub-process.

Step S720 d: defining the sub-process processing mode and establishing the sub-process sequence.

In this embodiment, specific processing behaviors of each sub-process on input/output data are described, and the processing manner includes data processing, time processing, fault processing, or redundancy processing.

The data processing mode is to describe the data processing behavior in the functional processing process, such as data acquisition, data calculation, logic judgment or fault tolerance processing; the time processing mode is to describe the processing behavior of time in the function processing process, such as time sequence processing, cycle processing, time limit judgment or abnormal interruption.

The fault processing mode is to describe the processing behavior of the data fault in the function processing process, such as fault diagnosis, fault recovery, fault reporting or fault warning; the redundancy processing mode is to describe the processing behavior of input data or output data redundancy in the function processing process, such as redundancy design, redundancy voting or redundancy switching.

In addition, according to each subprocess of function processing, a subprocess sequence is established, which comprises that according to the judgment condition of the judgment node, the condition execution relation of the subprocess is determined, and a condition process sequence is established; according to the time sequence relation among the sub-processes, determining that the sub-processes are sequentially executed or concurrently executed, and establishing a sequential process sequence or a concurrent process sequence; and determining the control direction between the sub-processes according to the control relation between the sub-processes, and establishing a control feedback process sequence.

Step S720 e: and the software functional model modeling process completes the inspection.

Specifically, whether all model elements of the software function reach 100% coverage or not is checked, the software function requirement reaches 100% coverage, and if yes, the modeling process of the software function model is completed; if not, the process returns to step S720c, and the above steps are repeated.

S730: and establishing a software working state model meeting modeling basis and requirements of software state transition.

The working state is subjective description of the airborne software capability, the range of a state object can be determined according to specific conditions, and the airborne software capability covered by different working states is determined.

In this embodiment, modeling bases and requirements for software state transition are embodied in a state object and boundary, a state and function mapping, a state transition condition, a mapping for establishing a transition condition and interface data, describing a state transition condition, dividing a state scene, establishing an initial ending state and a state scene, and establishing a software working state model in the form of characters, diagrams and formal languages according to the modeling bases and requirements.

In one embodiment, the step of establishing a software operating state model (not shown in the figures) comprises:

step S730 a: state objects and boundaries are defined and a mapping of states and functions is established.

In the embodiment, the state and the working mode required by airborne software are determined according to the state and the mode required by software requirement specification, and the unique name or the identification of the state is determined; and the boundary of the working state object is divided, and other working states or modes are distinguished.

In addition, according to the specification of software requirements, software functions which need to be executed and are not executed under the working state object are clarified, and relevant function information is obtained from the system function model.

Step S730 b: defining state transition conditions and establishing a mapping of the transition conditions with interface data

In this embodiment, determining all transition conditions of a state object and names or identifiers of the conditions according to the states and modes required by the "software requirement specification", specifically includes: entry conditions, branch conditions, and exit conditions.

The entry condition is a condition for determining an entry state object, and describes a unique name or an identification of the entry state object; the transfer condition is a condition for determining the transfer of the state object to other working states or the self circulation maintenance, and describes a unique name or an identification of the state object; an exit condition is a condition that determines an exit state object, describing its unique name or identification.

In addition, according to the specification of software requirements, the data elements of the external or internal interface of the software involved in the state transition condition are defined, and the information of the data elements is obtained from the external interface model of the software.

Step S730 c: state transition conditions are described.

Specifically, the state transition condition is a specific judgment basis for triggering state entry, transition or exit, and is usually a logical judgment condition consisting of data and time elements. Based on interface data elements mapped by state transition conditions in the external interface model of the software system, a standard model language is adopted to describe logic judgment conditions formed by the data elements or time elements.

Step S730 d: and dividing the state scene.

Specifically, according to the state and mode required by the software requirement specification, the divisible state scenes in the software running process are determined, and the software working state related to each scene is determined.

Step S730 e: initial and end states and state scenarios are established.

Specifically, according to the state scene division, for each scene, an operation starting point of the state scene is established as an initial state, and an operation end point of the state scene is established as an end state. The initial state and the end state are virtual state scene entrance and exit, and have no practical significance.

Step S730 f: and the modeling process of the software working state model completes the inspection.

Specifically, whether all model elements of the working state, the state transition condition and the state scene reach 100% coverage or not is checked, the requirement of the working state of the software reaches 100% coverage or not is checked, and if yes, the modeling process of the working state model of the software is completed; if not, the process returns to step S730a, and the above steps are repeated.

S740: and establishing a software system dependency relationship model meeting the modeling basis and requirements of the interface dependency relationship, the function dependency relationship and the state dependency relationship based on the software external interface model, the software function model and the software working state model.

The state dependency relationship is usually used to describe the relationship between different working states in the same state scene. And for the state dependency relationship among different state scenes, a new state scene is proposed, and the working state with the dependency relationship is represented in a new scene.

Specifically, the modeling basis and requirements of the software system dependency relationship model comprise a modeling interface dependency relationship, a modeling function dependency relationship and a modeling state dependency relationship, and the software system dependency relationship model is established in the form of characters, diagrams and formal languages by referring to the software external interface model, the software function model and the software working state model.

In one embodiment, the step of building a software system dependency model (not shown) comprises:

step S740 a: and quoting a software external interface model and modeling interface dependency.

Specifically, according to the specification of software requirements, interface data with dependency relationships are specified, and related interface data elements directly refer to a software external interface model.

In addition, an interface dependency relationship is established by referring to a software external interface model, and the interface dependency relationship comprises: an interface data constraint relationship, an interface time constraint relationship, and an interface logic constraint relationship.

The interface data constraint relationship is a data constraint relationship symbol which is used for describing a specific numerical relationship among related interface data elements, for example, the numerical relationship is greater than, equal to or less than; the interface time constraint relationship adopts a time constraint relationship symbol to describe the specific time sequence and period requirements among the related interface data elements, such as earlier than, simultaneously or later than; the interface logic constraint relation is to use logic constraint relation symbol to describe the specific processing logic between the related interface data elements, such as simultaneous effective, simultaneous ineffective or negation.

Step S740 b: and quoting a software functional model and modeling functional dependency.

Specifically, according to the specification of software requirements, a plurality of functions having dependency relationships are specified, and related function information directly refers to a software function model.

In addition, a function dependency relationship is established by referring to the software function model, and the function dependency relationship comprises a function time constraint relationship and a function logic constraint relationship.

Wherein, the function data constraint relation is a data constraint relation symbol, which describes the specific data processing process among a plurality of functions, such as addition, subtraction or numerical comparison; the function time constraint relation adopts a time constraint relation symbol to describe the specific time sequence and period requirements among a plurality of functions, such as sequential execution or concurrent execution; the function logic constraint relation adopts a logic constraint relation symbol to describe specific processing logic among a plurality of functions, such as simultaneous effective, simultaneous ineffective or negation.

Step S740 c: and quoting a software working state model and modeling a working state dependency relationship.

Specifically, according to the specification of software requirements, a plurality of operating states with dependency relationships are defined, and the software operating state model is directly referred to by the relevant state information.

In addition, the state dependency relationship is established by referring to a software working state model, and the working state dependency relationship comprises the following steps: a state data constraint relationship, a state time constraint relationship, and a state logic constraint relationship.

Wherein, the state data constraint relation is a data constraint relation symbol, which describes the specific data processing process among a plurality of working states, such as addition, subtraction or numerical comparison; the state time constraint relation adopts a time constraint relation symbol to describe specific time sequence and period requirements among a plurality of working states, and if the time constraint relation symbol is earlier or later than the specific time sequence and period requirements; the state logic constraint relation adopts a logic constraint relation symbol to describe specific processing logic among a plurality of working states, such as mutual exclusion.

Step S740 d: and the modeling process of the software system dependency model completes the check.

Specifically, whether all model elements of the dependency relationship reach 100% coverage is checked, and if yes, the modeling process of the software system dependency relationship model is completed; if not, the process returns to step S740a, and the above steps are repeated.

The software system hierarchy and dependency relationship model in the traditional technology is constructed by the following steps: 1) performing functional decomposition and data refinement on a target software system; 2) determining a software appointed hierarchy based on a function decomposition result, and constructing a system hierarchy structure chart; 3) and based on the result of data refinement, adding corresponding data dependent edges between leaf modules of the system hierarchy structure diagram. Usually, a problem decomposition and gradual refinement analysis method is adopted to decompose a target software system and its functions into a plurality of subsystems and functions, and a hierarchical structure of the system can be obtained through a top-down decomposition process, wherein the model is shown in fig. 8,

therefore, the hierarchical structure and the dependency relationship model emphasize the control flow and the data flow between the functional modules, and the specific description of the model is not accurate, such as specific logic inside the functional model, data characteristics of an interface, and the like are not reflected. It can be known that the main function of the hierarchical structure and the dependency relationship model is to analyze the cause and influence of software failure through control flow and data flow, and the guiding function of software failure mode analysis is low.

In the embodiment, a system preset requirement model of 'software external interface-software function-software working state' is constructed from bottom to top, and the purpose is to perform standardized, clear and explicit description on system requirements by a modeling means. When software system-level security analysis is subsequently carried out, the logic relation between the demand elements and the demands can be rapidly and accurately positioned and extracted according to the demand model, and the conversion of the software working state and the software failure caused by the combination of a plurality of functions are fully embodied.

Therefore, according to the preset demand model of the system, increasingly complex software failure modes such as interface fault combination, multifunctional interaction, state scene switching and the like are fully and effectively identified and analyzed, and scientific and reasonable basis is provided for the safety design of the system, so that equipment damage and software life cycle cost caused by software failure are reduced.

Accordingly, an embodiment of the present invention provides an apparatus for identifying a failure mode of software, as shown in fig. 9, including:

the dividing module 910 is configured to divide a preset requirement model for constructing software to obtain a software external interface model, a software function model, a software working state model and a software system dependency relationship model;

an independent function analysis module 920, configured to analyze an independent function failure mode of the software based on the software external interface model and the software functional model, and obtain an analysis result of the independent function failure mode; wherein the independent functional failure modes of the software comprise: a function input failure mode, a function processing process failure mode and a function output failure mode;

a function combination analysis module 930, configured to analyze a function combination failure mode of the software based on the software function model and the software system dependency relationship model, and obtain an analysis result of the function combination failure mode;

the state transition analysis module 940 is configured to analyze the state transition failure mode of the software based on the software working state model and the software system dependency relationship model to obtain an analysis result of the state transition failure mode;

the software failure reason identifying module 950 is configured to identify a reason for software failure according to an analysis result of the independent function failure mode, an analysis result of the function combination failure mode, and an analysis result of the state transition failure mode.

The device for identifying the failure mode of the software can execute the method for identifying the failure mode of the software provided by the embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

In addition, it can be understood by those skilled in the art that all or part of the processes in the methods for implementing the embodiments described above can be implemented by instructing the relevant hardware through a computer program, where the program can be stored in a non-volatile computer-readable storage medium, and in the embodiments of the present invention, the program can be stored in the storage medium of the computer system and executed by at least one processor in the computer system, so as to implement the processes of the embodiments including the method for identifying the failure mode of each software described above.

In one embodiment, a storage medium is further provided, on which a computer program is stored, wherein the program, when executed by a processor, implements the method for identifying a failure mode of software according to any one of the above embodiments. The storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), or the like.

The computer storage medium and the stored computer program fully embody the software failure caused by the conversion of the software working state and the combination of a plurality of functions by realizing the flow of the embodiment of the identification method of the failure mode of the software, fully embody the software failure caused by the conversion of the software working state and the combination of a plurality of functions, can analyze the software failure mode in all directions, have the advantages of strong universality, easy popularization and reproducibility, help research and development personnel to find the real reason and the potential threat of the software failure in the software development process, effectively promote the improvement of the safety design level in the software development stage, enhance the pertinence and the effectiveness of corrective measures, improve the safety of software products, and reduce the equipment damage and the software full life cycle cost caused by the software failure.

The embodiment of the present invention further provides a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and when the processor executes the computer program, the processor implements the steps of any one of the above methods.

The method has the advantages of strong universality, easy popularization and reproducibility, helping research and development personnel to find the real reason and potential threat of software failure in the software development process, effectively promoting the improvement of the safety design level in the software development stage, enhancing the pertinence and effectiveness of corrective measures, improving the safety of software products, and reducing equipment damage and software full-life cycle cost brought by software failure.

The above-mentioned embodiments only express several embodiments of the present invention, and the description thereof is more specific and detailed, but not construed as limiting the scope of the present invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the inventive concept, which falls within the scope of the present invention. Therefore, the protection scope of the present patent shall be subject to the appended claims.

Claims

1. A method for identifying a failure mode of software, comprising the steps of:

2. The method of identifying failure modes of software according to claim 1, wherein the step of analyzing the functional input failure modes comprises:

analyzing whether the input data model elements of each single input data with independent functions are abnormal or not based on the input data model elements for constructing the software external interface model;

after analyzing the input data model elements, arranging and combining the single input data to obtain a plurality of input data combination modes, and analyzing whether the input data combination modes are abnormal or not;

and after analyzing all the input data model elements and the input data combination mode, obtaining an analysis result of the functional input failure mode.

3. The method of identifying failure modes of software according to claim 1, wherein the step of analyzing the functional process failure modes comprises:

analyzing whether each subprocess model element is abnormal or not based on the subprocess model elements for constructing the software function model;

analyzing various processing mode model elements based on the processing mode model elements for constructing the software function model;

and after analyzing all the sub-process model elements and the processing mode model elements, obtaining an analysis result of the functional processing process failure mode.

4. The method of identifying failure modes of software according to claim 1, wherein the step of analyzing the functional output failure modes comprises:

analyzing whether the output data model element of each single output data is abnormal or not based on the output data model element for constructing the software external interface model;

after analyzing whether the output data model elements are abnormal or not, arranging and combining the single output data to obtain a plurality of combined output data, and analyzing whether the combined output data are abnormal or not;

and after analyzing all the output data model elements and the output data combination mode, obtaining an analysis result of the functional output failure mode.

5. The method for identifying failure modes of software according to any one of claims 1 to 4, wherein the step of analyzing the failure modes of the functional combinations of the software comprises:

analyzing whether each sub-function-sub-function combined model element is abnormal or not based on the sub-function-sub-function combined model element for constructing the software function model;

analyzing whether each function combination dependency model element is abnormal or not based on the function combination dependency model element for constructing the software system dependency model;

and after analyzing all the sub-function-sub-function combination model elements and the function combination dependency relationship model elements, obtaining an analysis result of the function combination failure mode.

6. The method of identifying failure modes of software according to claim 5, wherein the step of analyzing the state transition failure modes of the software comprises:

analyzing whether each working state model element is abnormal or not based on the working state model element for constructing the software working state model;

analyzing whether each state transition path model element is abnormal or not based on the state transition path model elements for constructing the software working state model and the software system dependency relationship model;

and after analyzing all the working state model elements and the state transition path model elements, obtaining an analysis result of the state transition failure mode.

7. The method for identifying the failure mode of the software according to any one of claims 1 to 4, characterized by further comprising, before the step of dividing a preset demand model for constructing the software, establishing the preset demand model; wherein the step of establishing the preset demand model comprises:

establishing a software external interface model meeting modeling basis and requirements of a software external interface;

the software external interface model is quoted, and the software function model meeting the modeling basis and the requirement of the software function is established;

establishing a software working state model meeting modeling basis and requirements of software state transition;

and establishing a software system dependency relationship model meeting modeling basis and requirements of an interface dependency relationship, a function dependency relationship and a state dependency relationship based on the software external interface model, the software function model and the software working state model.

8. An apparatus for identifying a failure mode of software, comprising:

9. A readable storage medium, on which a computer program is stored, characterized in that the program is executed by a processor for performing the steps of the method as claimed in any one of claims 1 to 7.

10. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the steps of the method of any of claims 1-7 are implemented when the program is executed by the processor.