A method for scenario and knowledge base driven failure mode identification and analysis

Abstract

The application provides a use scenario and knowledge base driven fault mode identification and analysis method, which can effectively identify complex fault modes and robust test case design without omission. The robust test design based on the use scenario needs to research the technical methods such as use scenario construction, use scenario based basic software FMEA analysis criterion, use scenario and knowledge base driven software FMEA analysis process, realizes the description of abnormal test scenarios such as error data processing, abnormal situation processing and illegal operation processing, simultaneously describes the combination test scenario based on the software use profile, simultaneously performs the robust test case design covering the fault modes based on the FMEA analysis result, and supports the software development and test personnel to carry out the software FMEA analysis, robust requirement acquisition and other work in the development process.

Description

Technical Field

[0001] This invention relates to the field of software system security technology, specifically to a fault mode identification and analysis method driven by usage scenarios and knowledge base. Background Technology

[0002] Software systems typically operate under complex scenarios involving extensive data interaction, multi-node collaboration, various operating states, and strict timing constraints. This leads to complex failure modes such as unauthorized access, abnormal interface data, concurrent read / write conflicts, simultaneous access by multiple nodes, and functional logic anomalies. Currently, due to a lack of effective failure mode identification and analysis technologies and knowledge data, product developers struggle to effectively identify various abnormal usage scenarios and subsequent failure modes of software systems. This results in omissions in robustness testing design, leaving numerous security vulnerabilities.

[0003] It is evident that existing technologies suffer from several problems, including insufficient development of usage scenarios by product developers and testing personnel, difficulty in effectively identifying complex failure modes, and the lack of a knowledge database suitable for failure mode analysis. Consequently, robust test case design lacks effective support and is prone to omissions. Summary of the Invention

[0004] In view of this, the present invention proposes a fault mode identification and analysis method driven by usage scenarios and knowledge base, which can effectively identify complex fault modes and ensure that robust test case design does not produce omissions.

[0005] To achieve the above objectives, the technical solution of the present invention is as follows:

[0006] A fault mode identification and analysis method driven by usage scenarios and knowledge base is proposed. Based on the robust test design of usage scenarios, the method constructs usage scenarios; based on the basic software FMEA analysis criteria of usage scenarios, and with the help of model-driven, data-driven, and ontology theories, it conducts software fault mode identification and analysis driven by usage scenarios and knowledge base. Simultaneously, based on the FMEA analysis results, it designs robust test cases covering fault modes; and establishes a mapping relationship between basic software FMEA analysis criteria, fault modes, and various usage scenario elements.

[0007] The scenario- and knowledge-driven basic software FMEA analysis framework specifically consists of: inputting software usage scenarios and a software fault knowledge base. The software usage scenarios include normal usage scenarios such as database management, database querying and operation, as well as abnormal scenarios such as error data scenarios, illegal operation scenarios, and exception handling scenarios. The software fault knowledge base includes FMEA analysis criteria for error data handling, exception handling, and illegal operation handling. The software fault mode and its impact analysis list includes fault causes, fault modes, regulatory impacts, control measures, and robustness requirements.

[0008] Based on the software operation process, normal usage scenarios, error data processing scenarios, abnormal situation processing scenarios, illegal operation processing scenarios, and combined scenarios based on usage profiles are constructed. Then, using ontology theory methods, the typical element information in the usage scenarios is decomposed, including interface data, functional logic, working status, timing constraints, and operation permissions.

[0009] The method for constructing software use cases based on ontology theory includes the following steps:

[0010] Step 11: Based on the terminology definition and classification requirements of software system usage scenarios, achieve an accurate understanding of the ontology modeling domain of software usage scenarios;

[0011] Step 12: Combine the content of normal and abnormal software usage scenarios to establish a usage scenario model based on ontology theory.

[0012] Step 13: Guided by typical software system usage scenarios, trim and refine various software ontology elements to form a software usage scenario model based on ontology theory, until the constraints of software fault mode identification analysis and robustness testing are met.

[0013] Based on the requirements of GJB 900A and GJB / Z 102A standards and typical usage scenario elements, and using first-order predicate logic and set theory, this study abstracts and refines the illegal access, abnormal interface data, invalid functional logic, concurrent read / write conflicts, process management anomalies, and multi-node access conflicts contained in the fault data. This forms standardized, unambiguous general fault modes and fault knowledge data for software FMEA analysis criteria, laying the foundation for robust test case design.

[0014] The specific criteria for software FMEA analysis are as follows:

[0015] Error Data Handling Analysis Guidelines: **Memory Allocation Anomaly Analysis:** Analyze and design the software's memory allocation process to confirm whether the software effectively detects and handles fault modes such as allocated space exceeding available space or allocation failure. **Data Read / Write Anomaly Analysis:** Analyze and design the software's data read / write process to confirm whether the software effectively detects and handles fault modes such as multiple connections concurrently operating on the same data, writing extremely large data blocks, frequent memory-to-disk data exchange, exceeding disk quotas, and high-concurrency, high-frequency read / write operations. **Data Value Anomaly Analysis:** Analyze and design the data value acquisition process to confirm whether the software handles fault modes such as illegal objects and data... The software performs effective detection and handling of fault modes such as values ​​exceeding the valid range and data not having initial values ​​set; communication transmission anomaly analysis: it analyzes and designs the communication transmission process between software interfaces to confirm whether the software effectively detects and handles fault modes such as excessively many-link communication, high-load communication, abnormal communication link interruption, repeated communication link connection, and incorrect data frame format; and anomaly timing constraint analysis: it analyzes and designs the interface timing constraints to confirm whether the software effectively detects and handles fault modes such as data acquisition period greater than the specified period, data acquisition time later than the specified time, and data acquisition duration greater than the specified duration.

[0016] Anomaly Handling Analysis Guidelines: Data Maintenance and Backup Anomaly Analysis: Analyze and design the software's data maintenance and backup process to confirm whether the software effectively detects and handles failure modes such as interruptions during import / export, backup / recovery processes, and import / export timeouts. Process Management Anomaly Analysis: Analyze and design the software's process and thread management to confirm whether the software effectively detects and handles failure modes such as continuous process creation, continuous thread creation, memory out-of-bounds access, and illegal pointers. Illegal Judgment Condition Analysis: Analyze and design functional judgment conditions to confirm whether the software effectively detects and handles failure modes such as judgment conditions changing from true to false or judgment conditions being true repeatedly. Anomaly Branch Path Analysis: Analyze and design different functional branch paths to confirm whether the software effectively detects and handles failure modes such as unreachable branch paths, multiple branch paths executing simultaneously, and conflicting or duplicate branch paths. Testing and Handling; Function Execution Timeout Analysis: Analyze and design the function execution sequence to confirm whether the software effectively detects and handles fault modes such as delayed function start, delayed function end, and function scheduling timeout; Function Concurrency Conflict Analysis: Analyze and design the execution conditions and processes of multiple functions to confirm whether the software effectively detects and handles fault modes such as control process conflicts and interface data value conflicts caused by the simultaneous execution of multiple functions; Function Sequence Anomaly Analysis: Analyze and design the execution order between multiple functions to confirm whether the software effectively detects and handles fault modes such as operation sequence anomalies, data sequence anomalies, and personnel behavior sequence anomalies between multiple functions; Equipment Call Conflict Analysis: Analyze and design the equipment accessed or called by the function to confirm whether the software effectively detects and handles fault modes such as data resource conflicts and equipment control conflicts caused by multiple functions simultaneously reading data.

[0017] Illegal Operation Handling Analysis Criteria: Invalid Access Permission Analysis: Analyze and design the software user permissions and their settings to confirm whether the software effectively detects and handles fault modes such as unauthorized access, lack of access permissions, database access restrictions, and read / write permission errors; Abnormal Device Status Analysis: Analyze and design the software for operation-related external devices to confirm whether the software effectively detects and handles fault modes such as device power failure and devices in an initialization state; Illegal Operation Behavior Analysis: Analyze and design the software for personnel operation behavior to confirm whether the software effectively detects and handles fault modes such as personnel misoperation, incorrect operation, and rapid operation; Invalid Operation Process Analysis: Analyze and design the software for personnel operation processes and activities to confirm whether the software effectively detects and handles fault modes such as invalid operation, abnormal operation interruption, device non-response to operation commands, inconsistency with software operation specifications, and incorrect execution sequence.

[0018] This involves developing corresponding checklists based on established FMEA analysis criteria for various basic software applications, creating actionable checklists covering diverse usage scenarios and failure modes. These checklists support basic software designers in checking for discrepancies between the software analysis and design and the criteria, identifying potential safety hazards. The compliance checklist process for basic software requirements design is as follows: Based on various FMEA analysis criteria, a comprehensive analysis and check is performed on the requirements design elements in normal software usage scenarios and various abnormal scenarios. If the requirements design elements in the software usage scenarios are fully implemented… If the criterion is implemented, fill in YES in the Compliance Check column and describe the relevant content of the analysis criterion implementation in the Description column. If the criterion is not applicable to the requirement design elements in the current use case, fill in N and A in the Compliance Check column and describe the reason for the inapplicability of the criterion and the relevant inapplicable design content in the Description column. If the requirement design elements in the use case do not implement the criterion, fill in NO in the Compliance Check column and describe the relevant requirement design content that does not implement the criterion in the Description column, and conduct further analysis to clarify the possible failure problems caused when the use case does not conform to the analysis criterion.

[0019] Among them, based on the usage scenario and analysis criteria, a formal analysis algorithm for software failure modes is adopted, which is based on the usage scenario of the external interface ontology and the corresponding analysis criteria, including the first analysis criterion and the second analysis criterion.

[0020] The first analytical criterion is to examine the analog input interface data of the software and analyze whether the software has handled the data correctly when the value of the analog input interface data is greater than the upper limit of the boundary value of the value range.

[0021] The second analysis criterion is to examine the concurrent operation of multiple functions, analyze whether the software has handled the conflicting values ​​caused by multiple functions performing different processing operations on an output interface.

[0022] Beneficial effects:

[0023] 1. The robust test design based on usage scenarios of this invention requires research into technical methods such as usage scenario construction, basic software FMEA analysis criteria based on usage scenarios, and software FMEA analysis process driven by usage scenarios and knowledge base. It realizes the description of abnormal test scenarios such as error data processing, abnormal situation processing, and illegal operation processing. At the same time, it describes the combined test scenarios based on software usage profiles. Furthermore, based on FMEA analysis results, it designs robust test cases that cover failure modes, supporting software development and testing personnel to carry out software FMEA analysis and robustness requirement acquisition that meet standard requirements during the development process.

[0024] 2. Based on the software operation process, this invention constructs various usage scenarios, such as normal usage scenarios, error data handling scenarios, abnormal situation handling scenarios, illegal operation handling scenarios, and combined scenarios based on usage profiles. Then, using ontology theory, it decomposes typical element information within these usage scenarios, including interface data, functional logic, working status, timing constraints, and operation permissions. This provides a typical foundation for software fault mode identification and analysis, covering as many external abnormal stimuli and complex usage scenarios as possible during software operation. This ensures the accuracy and sufficiency of robustness testing, enabling software developers and testers to fully identify security vulnerabilities in software requirement design, formulate software robustness requirements and design strategies, improve the software's ability to withstand abnormal and complex fault modes, operate safely and stably, and continuously provide services, ensuring that the software product quality meets system requirements.

[0025] 3. Based on the requirements of standards such as GJB 900A, GJB, and Z 102A, and typical usage scenario elements, this invention, using historical project fault data and pattern theories such as first-order predicate logic and set theory, abstracts and refines the fault mechanisms contained in the fault data, such as illegal access, abnormal interface data, invalid functional logic, concurrent read-write conflicts, process management anomalies, and multi-node access conflicts. This forms standardized, unambiguous general fault modes and software FMEA analysis criteria, laying the foundation for robust test case design.

[0026] 4. Based on the identified fault modes, this invention constructs a mapping relationship between software fault modes, FMEA analysis criteria, and various usage scenario elements, taking into account the characteristics of the usage scenarios. This guides developers to match and recommend the most relevant FMEA analysis criteria and fault modes based on usage scenario elements during software fault mode identification and analysis. It fully identifies various fault modes from multiple perspectives, including "error data handling, abnormal situation handling, and illegal operation handling," comprehensively covering abnormal stimuli and complex scenarios in the operation of software systems such as data processing servers and cloud servers. This identifies software security vulnerabilities and weaknesses, improving the efficiency and quality of robustness testing. It ensures that robustness test design fully verifies software abnormal stimuli and complex scenarios, reducing security risks during software operation and increasing the coverage and error detection rate of robustness testing. Furthermore, based on the constructed fault knowledge base, robustness test cases can be continuously revised and improved during the iterative development and testing of software products, forming highly reusable test cases and typical cases, improving software product quality, reducing software testing costs, and ensuring high software security and reliability. Attached Figure Description

[0027] Figure 1 This is a schematic diagram illustrating the overall concept of the present invention.

[0028] Figure 2 This is a schematic diagram illustrating the constraints for software fault mode identification and analysis, robustness testing, and other tasks in this invention.

[0029] Figure 3 This is a schematic diagram of the software usage scenario model based on ontology theory of the present invention.

[0030] Figure 4 This is a schematic diagram of the FMEA analysis framework, which is the foundational software for scenario and knowledge-driven learning in this invention. Detailed Implementation

[0031] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0032] If the use case involves the operation of a single scenario or a combination of multiple scenarios within a specific process in an application system during actual application, scenarios with similar functions or attributes will generate different use cases under different combinations or processes. These various use cases collectively support the functional scenarios of the application system. Designing robustness tests based on use cases can more closely resemble real-world operational processes, making test items more targeted, test plans more comprehensive, and test results more illustrative. The selection and design of use cases in software system robustness testing needs to be carried out from different levels and multiple dimensions, including two main categories: normal use cases and abnormal use cases. Among these, the identification and analysis of abnormal use cases is the core content and an important prerequisite for robustness testing. Therefore, to ensure the effectiveness and adequacy of robustness testing, software failure mode identification needs to be performed first, providing a foundation for constructing abnormal use cases and designing test cases in robustness testing.

[0033] This invention utilizes model-driven, data-driven, and ontology-based technologies to research software fault mode and analysis techniques driven by usage scenarios and knowledge bases. Based on software requirements design and operational characteristics, complex software usage scenarios (especially abnormal usage scenarios) are constructed. Then, based on these usage scenarios, corresponding fault modes are automatically matched from a fault knowledge base, achieving software fault mode and analysis driven by usage scenarios and data. The overall approach is as follows: Figure 1 As shown, the details are as follows:

[0034] Step 1: Based on the software operation process, construct various usage scenarios, including normal usage scenarios, error data handling scenarios, exception handling scenarios, illegal operation handling scenarios, and combined scenarios based on usage profiles. Then, using ontology theory methods, decompose the typical element information in the usage scenarios, including interface data, functional logic, working status, timing constraints, and operation permissions, providing a typical foundation for software fault mode identification and analysis. Specifically:

[0035] Specifically, addressing the requirements of fault mode identification (FMEA) analysis, this paper proposes a software usage scenario design and construction technique to provide basic input for software FMEA analysis. This technique includes two parts: normal usage scenarios and abnormal usage scenarios. In other words, the software usage scenario construction content includes the construction content for both normal and abnormal usage scenarios, as detailed below:

[0036] Normal Usage Scenarios Construction Content: First, based on the normal operating procedures and task scenarios of domestically developed basic software products such as data processing servers and cloud servers, typical application scenarios are analyzed. Information such as normal operating procedures, timing relationships, data interactions, and hardware-software coupling under various application scenarios is extracted to construct different categories of normal operating scenarios, such as database management scenarios, database query and operation scenarios, database maintenance scenarios, data computation scenarios, data storage scenarios, and network transmission scenarios. Specific content includes:

[0037] Database management scenarios include: storage management, data file management, data object definition, user management, and permission settings; database query and operation scenarios include: CRUD operations on millions of data entries, providing normal scenarios for defining data such as tables, views, stored procedures, indexes, and sequences; database maintenance scenarios include: data import / export, backup / restore, and other normal scenarios; data computation scenarios include: complex multi-process and multi-threaded calculations, process and thread communication, memory access, and disk read / write; data storage scenarios include: normal scenarios such as multi-process file read / write; and network transmission scenarios include: normal scenarios such as TCP and UDP transmission.

[0038] The content of abnormal use case construction includes: designing abnormal operation scenarios for three types of exception handling: error data handling, abnormal situation handling, and illegal operation handling. Specific content includes:

[0039] a) Error Data Handling Scenarios: Based on the requirements design and other specifications, tests are conducted on elements such as input data, communication methods, timing constraints, and data concurrency. The focus is on designing abnormal operation scenarios such as space allocation anomalies, data read / write anomalies, data value anomalies, communication transmission anomalies, and abnormal timing constraints, as described below: Space Allocation Anomalies: These include scenarios such as allocating more space than available space and space allocation failure; Data Read / Write Anomalies: These include scenarios such as multiple connections concurrently operating on the same data, writing extremely large data blocks, frequent memory-to-disk data exchange, exceeding disk quotas, and high-concurrency, high-frequency read / write operations; Data Value Anomalies: These include scenarios such as illegal objects, data values ​​exceeding the valid value range, and data without initial values; Communication Transmission Anomalies: These include scenarios such as excessively many communication links, high-load communication, abnormal communication link interruptions, repeated communication link connections, and incorrect data frame formats; Abnormal Timing Constraints: These include scenarios such as data acquisition periods exceeding the specified periods, data acquisition times later than the specified times, and data acquisition durations exceeding the specified durations.

[0040] b) Abnormal Situation Handling Scenarios: Based on the requirements design and other specifications, tests are conducted on requirement elements such as judgment conditions and equipment status. The focus is on designing operational scenarios such as data maintenance and backup anomalies, process management anomalies, illegal judgment conditions, abnormal branch paths, function execution timeouts, function concurrency conflicts, function serialization anomalies, and device call conflicts. These are described as follows: Data maintenance and backup anomalies: including scenarios such as interruption of import / export processes, backup / restore processes, and import / export timeouts; Process management anomalies: including scenarios such as continuous process creation, continuous thread creation, memory out-of-bounds access, and illegal pointers; Illegal judgment conditions: including scenarios such as judgment conditions changing from true to false, and judgment conditions being true repeatedly; Abnormal branch paths: including scenarios such as unreachable branch paths, simultaneous execution of multiple branch paths, and conflicting or duplicated branch paths; Function execution timeouts: including scenarios such as delayed function start, delayed function end, and function scheduling timeouts; Function concurrency conflicts: including scenarios such as control process conflicts and interface data value conflicts caused by the simultaneous execution of multiple functions; Function serialization anomalies: including scenarios such as abnormal operation sequences between multiple functions, abnormal data sequences, and abnormal personnel behavior sequences; Device call conflicts: including scenarios such as conflicts in multiple functions simultaneously reading data resources and device control conflicts.

[0041] c) Illegal Operation Handling Scenarios: Based on the requirements design and other specifications, tests are conducted on requirement elements such as personnel operation behavior, personnel access permissions, associated device status, and operation process. The focus is on designing operation scenarios such as invalid access permissions, abnormal device status, illegal operation behavior, and invalid operation process, as described below: Invalid access permissions: including scenarios such as providing unauthorized access, not setting access permissions, database access prohibition, and read / write permission errors; Abnormal device status: including scenarios such as device power failure and device initialization; Illegal operation behavior: including scenarios such as misoperation, incorrect operation, and rapid operation; Invalid operation process: including scenarios such as invalid operation, abnormal operation interruption, device not responding to operation commands, inconsistency with software operation specifications, and execution sequence errors.

[0042] This embodiment adopts a software use scenario construction method based on ontology theory, including the following steps:

[0043] Step 11, Domain Understanding of Ontology Modeling for Failure Mode and Effects Analysis: Based on the terminology definitions and classification requirements of software system usage scenarios, achieve an accurate understanding of the ontology modeling domain for software usage scenarios. This involves describing software usage scenarios in a form that is understandable to both software security and reliability personnel and software developers. This allows for close integration of software failure mode identification and analysis with the software development process, avoiding inconsistencies in usage scenario understanding between software security and reliability personnel and developers, reducing the costs of software failure mode identification and analysis, robustness testing and evaluation, and improving the efficiency of software development.

[0044] Step 12, Constraints on Use Case Modeling Based on Ontology Theory: The use case model built based on software requirements describes various scenario elements, primarily geared towards developers. For software security and reliability personnel, there may be issues such as weak correlation between use cases (especially abnormal use cases) and security and reliability. This results in significant effort being spent building the use case model without significantly improving the efficiency of software fault mode identification and analysis. Therefore, this patent constrains the use case modeling method and content based on ontology theory from the perspectives of software fault mode identification and analysis and robustness testing. That is, by combining the content of the above-mentioned normal and abnormal software use cases, an ontology-based use case model is established to quickly improve the efficiency and quality of software fault mode identification and analysis with minimal cost.

[0045] Step 13, Software Use Case Modeling Framework Based on Ontology Theory: Guided by typical software system use cases, various software ontology elements (including functions, interfaces, states, etc.) are tailored and refined to form a software use case model based on ontology theory, until the constraints for software fault mode identification analysis, robustness testing, etc., are met. The constraints are as follows: Figure 2 As shown.

[0046] Based on the aforementioned ontology modeling theory and relevant standard requirements, and combined with the content of normal and abnormal usage scenarios of software systems, an ontology-based software usage scenario model is as follows: Figure 3 As shown, the software use scenario model based on ontology theory in this invention includes the following parts:

[0047] (1) The usage scenario model based on the external interface ontology can standardize the description of software external interfaces and their interconnection environment information. It can perform standardized modeling analysis and configuration of requirements such as external interconnection devices, external interface types, and interface data frames. It supports common software interface types such as Ethernet, digital signals, analog signals, and human-machine interfaces. At the same time, it can also perform standardized modeling description and configuration of physical variable data in external interfaces, including variable names, data types, units, resolutions, valid data segments, associated data frames, and frame variables. The usage scenario modeling content based on the external interface ontology is as follows: Interface name: The unique name or identifier of software input and output interface data; Interface type: The interface type corresponding to software input and output interface data, such as analog signals, digital signals, Ethernet (UDP and TCP), human-machine interfaces, data buses, etc.; Value range: The valid value range of software input and output interface data, etc. If the interface data is discrete data, the value range is a set of several enumerated values; if the interface data is continuous data, the value range is a continuous value interval [LB, UB]. Wherein, LB represents the lower boundary of the value domain, and UB represents the upper boundary of the value domain; timing constraints: the value acquisition period, value acquisition time, duration, etc. of input and output interface data; communication protocols: such as communication data format, communication connection, buffer settings, storage location, etc.; fault strategies: fault diagnosis strategies, fault handling strategies, fault reset strategies, default values, etc. of software input and output interface data; interconnection devices: the input source device or output destination device corresponding to the software input and output interface data, such as sensors, actuators, etc.

[0048] (2) A usage scenario model based on the functional logic ontology. This model can establish the mapping relationship between functional items and external input interfaces and external output interfaces, and clarify the association relationship between functional items and different working states. At the same time, it can perform standardized modeling description and configuration for the processing logic and operation process in the functional requirements. This includes requirement elements such as judgment conditions, branch paths, operations, and interactive data. The usage scenario modeling content based on the functional logic ontology is as follows: Functional input and output data mapping: Describe all relevant input and output data of the function. It should be noted that the input and output data corresponding to the function (such as pressure, temperature, etc.) should be clearly defined here, rather than interface information; Functional processing logic: Describe the processing logic for different input and output data during the function processing, including input and output processing, logical judgment conditions, conditional branch processing, etc.

[0049] (3) A use case model based on a functional hierarchy ontology, which can describe the hierarchical relationships between multiple software functional items from top to bottom. The use case model based on the functional logic ontology includes the following: Functional hierarchy relationship: describing the hierarchical relationship between functions; Functional constraint relationship: after determining the functional hierarchy relationship, the constraint relationship between functions can be described. For example, value constraints, timing constraints, mutual exclusion constraints, etc.

[0050] (4) Use case model based on working state ontology. This model can graphically describe all working states and modes of the software, and the transition relationships between them, through a software working state diagram. The use case model based on working state ontology includes the following: Working State: All possible working states or modes during software operation; Transition Condition: The conditional relationship for a working state to transition to other working states. Transition conditions can usually be described by external input / output interfaces, functions, and other requirement model elements. A working state has both a preceding transition condition and a subsequent transition condition; Initial State: The starting point of software operation, used only for the initial description of the state transition diagram and has no practical meaning; Final State: The ending point of software operation, used only for the final description of the state transition diagram and has no practical meaning.

[0051] Step 2: Based on the requirements of standards such as GJB 900A, GJB, and Z 102A, and typical usage scenario elements, and using historical project fault data, this step abstracts and refines the fault mechanisms contained in the fault data, such as illegal access, abnormal interface data, invalid functional logic, concurrent read / write conflicts, process management anomalies, and multi-node access conflicts, using pattern theories such as first-order predicate logic and set theory. This forms standardized, unambiguous general fault modes and software FMEA analysis criteria, laying the foundation for robust test case design.

[0052] Specifically, in this embodiment, considering usage scenarios such as normal software use, error data handling, abnormal situation handling, and illegal operation handling, and referring to the requirements of standards such as GJB and Z 102A, the following FMEA analysis criteria for robustness testing of basic software are formulated from aspects such as "error data handling, abnormal situation handling, and illegal operation handling":

[0053] (1) Error Data Processing Analysis Criteria: Support developers in proposing corresponding FMEA analysis criteria based on "error data processing usage scenarios," targeting software input data, communication methods, timing constraints, data concurrency, and other requirements. This enables the identification and analysis of error data-related fault modes such as space allocation anomalies, data read / write anomalies, data value anomalies, communication transmission anomalies, and abnormal timing constraints. Specific approaches are as follows: Space Allocation Anomaly Analysis: Analyze and design the software memory space allocation process to confirm whether the software effectively detects and handles fault modes such as "allocated space greater than available space" and "allocation failure." Data Read / Write Anomaly Analysis: Analyze and design the software data read / write process to confirm whether the software effectively detects and handles fault modes such as "multiple connections concurrently operating on the same data," "writing extremely large data blocks," "frequent memory-hard disk data exchange," "writing exceeding disk quota," and "high-concurrency, high-frequency read / write." Data Value Anomaly Analysis: Analyze and design data value acquisition to confirm whether the software effectively handles fault modes such as "illegal objects," "data value anomalies," and "illegal objects." The software performs effective detection and handling of fault modes such as "values ​​exceeding the valid range, data without initial values"; communication transmission anomaly analysis: analyzes and designs the communication transmission process between software interfaces to confirm whether the software effectively detects and handles fault modes such as "multiple-link communication, high-load communication, abnormal interruption of communication links, repeated connection of communication links, and incorrect data frame format"; abnormal timing constraint analysis: analyzes and designs the interface timing constraints to confirm whether the software effectively detects and handles fault modes such as "data acquisition period greater than the specified period, data acquisition time later than the specified time, and data acquisition duration greater than the specified duration".

[0054] (2) Abnormal Situation Handling Analysis Criteria: Based on the “abnormal situation handling usage scenario”, the developers can propose corresponding FMEA analysis criteria for software data maintenance and backup, process and thread management, judgment conditions, equipment status, function timing and other requirements. This enables the identification and analysis of error data-related fault modes such as abnormal data maintenance and backup, abnormal process management, illegal judgment conditions, abnormal branch paths, function execution timeout, function concurrency conflict, function seriality exception, and device call conflict. The specific approaches are as follows: Data maintenance and backup anomaly analysis: Analyze and design the software's data maintenance and backup process to confirm whether the software effectively detects and handles fault modes such as "interruption during import / export, backup / restore process, and import / export timeout"; Process management anomaly analysis: Analyze and design the software's process management and thread management to confirm whether the software effectively detects and handles fault modes such as "continuous process creation, continuous thread creation, memory out-of-bounds access, and illegal pointers"; Illegal judgment condition analysis: Analyze and design the functional judgment conditions to confirm whether the software effectively detects and handles fault modes such as "judgment conditions changing from true to false, and judgment conditions being true repeatedly"; Abnormal branch path analysis: Analyze and design different functional branch paths to confirm whether the software effectively detects and handles fault modes such as "branch path unreachable, multiple branch paths executing simultaneously, and branch path conflicts or duplications". Handling; Function execution timeout analysis: Analyze and design the function execution sequence to confirm whether the software effectively detects and handles fault modes such as "function delayed start, function delayed end, and function scheduling timeout"; Function concurrency conflict analysis: Analyze and design the execution conditions and processes of multiple functions to confirm whether the software effectively detects and handles fault modes such as "control process conflicts and interface data value conflicts caused by simultaneous execution of multiple functions"; Function serial anomaly analysis: Analyze and design the execution order between multiple functions to confirm whether the software effectively detects and handles fault modes such as "operation sequence anomalies, data sequence anomalies, and personnel behavior sequence anomalies"; Device call conflict analysis: Analyze and design the devices accessed or called by the functions to confirm whether the software effectively detects and handles fault modes such as "conflicts in simultaneous data resource reading by multiple functions" and "device control conflicts".

[0055] (3) Illegal operation handling analysis criteria: Based on the “illegal operation handling usage scenario”, the R&D personnel can propose corresponding FMEA analysis criteria for the required elements such as personnel operation behavior, access permissions, associated equipment status, and operation process, so as to realize the identification and analysis of fault modes such as invalid access permissions, abnormal equipment status, illegal operation behavior, and invalid operation process. The specific approaches are as follows: Invalid access permission analysis: Analyze and design the software user permissions and their settings to confirm whether the software effectively detects and handles fault modes such as "unauthorized access, no access permissions set, database access prohibited, and read / write permission errors"; Abnormal device status analysis: Analyze and design the software for operation-related external devices to confirm whether the software effectively detects and handles fault modes such as "device power failure" and "device in initialization state"; Illegal operation behavior analysis: Analyze and design the software for personnel operation behavior to confirm whether the software effectively detects and handles fault modes such as "personnel misoperation, incorrect operation, and rapid operation"; Invalid operation process analysis: Analyze and design the software for personnel operation processes and activities to confirm whether the software effectively detects and handles fault modes such as "invalid operation, abnormal operation interruption, device not responding to operation commands, inconsistency with software operation specifications, and execution sequence errors".

[0056] Step 3: Based on the software FMEA analysis criteria, conduct failure mode and impact analysis based on usage scenarios and fault knowledge data. Specifically, establish a software failure mode identification and analysis framework, clarifying the analysis process and output formats, including failure cause analysis, failure mode analysis, failure impact analysis, control measures, and robustness requirement acquisition. Alternatively, based on typical software failure modes and analysis criteria, a checklist can be created to guide developers in conducting comprehensive analysis of important usage scenario elements such as data processing, data acquisition, process management, and data storage in the basic software, ensuring the standardization and sufficiency of the analysis process. In this embodiment, it supports developers in conducting systematic comprehensive analysis of various usage scenario elements according to the software FMEA analysis criteria, ensuring the standardization and sufficiency of the analysis process. The scenario- and knowledge-driven basic software FMEA analysis framework is as follows: Figure 4 As shown, the explanation is as follows:

[0057] The software usage scenarios and software fault knowledge base are included. Software usage scenarios include normal usage scenarios such as database management, database query and operation, as well as abnormal scenarios such as error data scenarios, illegal operation scenarios, and exception handling scenarios. The software fault knowledge base includes FMEA analysis criteria for categories such as error data handling, exception handling, and illegal operation handling, and a list of software fault modes and their impact analysis, including fault causes, fault modes, regulatory impacts, control measures, and robustness requirements.

[0058] The FMEA analysis process based on error data processing includes:

[0059] Based on the "FMEA Analysis Guidelines for Error Data Processing," software failure mode and impact analysis (FMEA) is conducted for both normal usage scenarios and error data processing scenarios, following these steps: Software Failure Cause Analysis: Following the "FMEA Analysis Guidelines for Error Data Processing," identify potential causes of software failures based on scenario elements such as input data, communication methods, timing constraints, and data concurrency. These causes include categories such as abnormal space allocation, abnormal data read / write, abnormal data retrieval, abnormal communication transmission, and abnormal timing constraints. Software Failure Mode Analysis: Based on the failure causes, analyze the abnormal functional output data that may result from the failure causes, combined with the functional execution logic under both normal usage and error data processing scenarios. Examples include stopped data output, timed-out data output, and outputting erroneous data. Software Failure Mode Impact Analysis: For different categories of failure modes, describe their impact on the underlying software system from the perspectives of operational safety and task completion. Furthermore, based on the failure impact analysis results, the failure impact can be graded, for example, categorized as catastrophic, severe, general, or minor. This provides support for obtaining software robustness requirements. Refer to Table 1 for the failure impact levels to analyze and grade the impact of software failure modes.

[0060] Table 1 Software Failure Mode and Effects Analysis and Level List

[0061]

[0062] Software Control Measure Development: Based on the causes and impact levels of software failures, control measures are determined, and software robustness requirements are obtained. Specific details are as follows: **Determining Control Measure Categories:** Based on the failure impact level, system designers and software developers jointly decide whether to add control measures for erroneous data processing failures. **Determining Control Measure Content:** Based on the failure causes, from the perspectives of input data, communication methods, timing constraints, and data concurrency, system designers and software developers jointly determine whether to add protective or design-based control measures for the basic software. **Obtaining Software Robustness Requirements:** Control measures implemented at the software level are formulated into clear, implementable, and verifiable software robustness requirements based on relevant standards. **Developing Software Robustness Design Strategies:** Based on the obtained robustness requirements, and referring to standard requirements, robust design strategies related to interface data are proposed from the perspectives of interface design, human-machine interface design, and data access design to effectively control erroneous data-related failure modes.

[0063] Based on the FMEA analysis guidelines for handling abnormal situations, software failure mode and impact analysis (FEMA) is conducted in both normal usage scenarios and abnormal situation handling scenarios, following these steps:

[0064] Software Failure Cause Analysis: Based on the "FMEA Analysis Guidelines for Exception Handling," identify potential causes of software failures for scenario elements such as data maintenance and backup, process and thread management, decision conditions, and device status. These causes include data maintenance and backup anomalies, process management anomalies, illegal decision conditions, abnormal branch paths, function execution timeouts, function concurrency conflicts, function serialization anomalies, and device call conflicts. Software Failure Mode Analysis: Building upon the causes of failures, analyze the functional execution logic under normal usage scenarios and exception handling scenarios to determine the abnormal functional output data that may result from the failure causes. Examples include stopped data output, timed-out data output, and outputting erroneous data. Software Failure Impact Analysis: The process is the same as the FMEA analysis based on error data handling.

[0065] Software Control Measure Development: Based on the causes and impact levels of software failures, control measures are determined, and software robustness requirements are obtained. Specific details are as follows: **Determining Control Measure Categories:** Based on the failure impact level, system designers and software developers jointly decide whether to add control measures for handling abnormal situations. **Determining Control Measure Content:** Based on the failure causes, from the perspectives of data maintenance and backup, process and thread management, judgment conditions, and equipment status, system designers and software developers jointly determine whether to add protective or design-based control measures for the basic software. **Obtaining Software Robustness Requirements:** Control measures implemented at the software level are defined as clear, implementable, and verifiable software robustness requirements based on relevant standards. **Developing Software Robustness Design Strategies:** Based on the obtained robustness requirements, and referring to standard requirements, relevant robustness design strategies can be proposed from the perspectives of real-time maintenance and backup, process optimization management, judgment condition monitoring, and branch path handling to achieve sufficient control over failure modes related to handling abnormal situations.

[0066] Based on the FMEA analysis criteria for handling illegal operations, software failure mode and impact analysis (FEMA) is conducted for both normal use scenarios and illegal operation handling scenarios, following these steps:

[0067] Software Failure Cause Analysis: Based on the "FMEA Analysis Criteria for Illegal Operation Handling," identify potential causes of software failures by considering scenario elements such as personnel operation behavior, personnel access permissions, associated equipment status, and operation processes. These causes include categories such as invalid access permissions, abnormal equipment status, illegal operation behavior, and invalid operation processes. Software Failure Mode Analysis: Building upon the causes of failures, analyze the abnormal functional output data that may result from the failures, considering both normal usage scenarios and illegal operation handling scenarios. Examples include stopped data output, timed-out data output, and erroneous data output. Software Failure Impact Analysis: Follows the same process as the FMEA analysis based on error data handling. Software Control Measure Development: Determine control measures based on the causes and impact levels of software failures and obtain software robustness requirements. The specific content is as follows: Determine the category of control measures: Based on the impact level of the fault, system designers and software developers jointly decide whether to add control measures to address unauthorized operation faults; Determine the content of control measures: Based on the cause of the fault, from the perspectives of personnel operation behavior, personnel access permissions, associated equipment status, and operation process, system designers and software developers jointly determine whether to add protective control measures or design-based control measures for the basic software; Obtain software robustness requirements: Based on relevant standards, formulate clear, implementable, and verifiable robustness requirements for the control measures implemented at the software level; Develop software robustness design strategies: Based on the obtained robustness requirements, and referring to standard requirements, propose robustness design strategies related to operation behavior from the perspectives of personnel operation specifications, access permission settings, equipment status judgment, and operation process monitoring to achieve sufficient control over unauthorized operation fault modes.

[0068] A key component of the aforementioned framework is establishing a mapping relationship between basic software FMEA analysis criteria, failure modes, and various usage scenario elements. During FMEA analysis, developers are guided to match and recommend the most relevant FMEA analysis criteria based on usage scenario elements, identifying various failure modes from multiple perspectives such as "error data handling, abnormal situation handling, and illegal operation handling." This comprehensively covers the abnormal stimuli and usage scenarios that cause basic software failures, identifies software security vulnerabilities and weaknesses, improves the efficiency and quality of basic software FMEA analysis and robustness testing, and also provides iterative feedback for robust design improvements and optimizations of basic software.

[0069] In this embodiment, based on the established FMEA analysis criteria for various basic software, corresponding checklists are developed to form an operable checklist covering various usage scenarios and failure modes. The checklists created for different categories of FMEA analysis criteria, such as "error data handling," "abnormal situation handling," and "illegal operation handling," are shown in Tables 2-4, as detailed below:

[0070] Table 2 Example of a compliance checklist for “Error Data Handling” analysis criteria

[0071]

[0072]

[0073] Table 3. Example of a compliance checklist for "Abnormal Situation Handling" analysis criteria.

[0074]

[0075] Table 4 Example of a compliance checklist for "Handling of Illegal Operations" analysis criteria

[0076]

[0077]

[0078] Based on the aforementioned checklists of different categories, support is provided for basic software designers to conduct checks on various usage scenarios and failure modes, identify security risks arising from non-compliance between basic software analysis and design and the established guidelines, and increase the focus of corresponding robustness testing. The process of checking basic software requirements design based on the compliance checklist is as follows: According to various FMEA analysis guidelines, a comprehensive analysis and check is performed on the requirements design elements in normal software usage scenarios and various abnormal scenarios. If the requirements design elements in the software usage scenarios fully implement the guidelines, then "YES" is entered in the "Compliance Check" column. The relevant content of the implemented analysis guidelines is described in the "Explanation" column. If the guidelines are not applicable to the requirements design elements in the current usage scenario, then "N and A" are entered in the "Compliance Check" column. The reason for the inapplicability of the guidelines and the relevant inapplicable design content is described in the "Explanation" column. If the requirements design elements in the usage scenario do not implement the guidelines, then "NO" is entered in the "Compliance Check" column. The relevant requirements design content that did not implement the guidelines is described in the "Explanation" column. Further analysis will be conducted to clarify the potential failures that may arise when the usage scenarios do not conform to the analysis criteria.

[0079] Based on the usage scenario and analysis criteria, this embodiment adopts a formal analysis algorithm for software failure modes. The algorithm is explained below, using the usage scenario of the external interface ontology and the corresponding analysis criteria:

[0080] First analysis criterion: Examine the analog input interface data of the software, and analyze whether the software has handled the situation correctly when the analog input interface data value exceeds the upper limit of the value range boundary. The specific process is as follows:

[0081] Determine if the current interface can be analyzed using the first analysis criterion. That is, analyze whether the software function input interface is of the "analog quantity" type and has a value range. If so, use the first analysis criterion; otherwise, stop the analysis. Based on the software interface ICD model, determine the value range of the input interface data, denoted as [L]. B U B The data range of the analog input interface may be segmented; in this case, [L] can be considered... B U B [This is a defined range]; based on the first analysis criterion, the failure mode of the analog input interface data is identified as "the value is greater than the upper limit of the value interval boundary, that is, the input interface data value > U". B As a cause of software failure, the functions related to the input interface data are determined based on the software usage scenario model. The output interface data resulting from the functional processing after the interface failure mode is analyzed, i.e., the identified software failure mode; then, based on the software usage scenario model, the impact of the software failure is determined; and based on the cause of the software failure (input interface data value > U), the impact is determined. B The document outlines the corresponding functional processing procedures, proposes appropriate control measures (such as the software using the effective value from the previous cycle), and establishes security requirements.

[0082] The second analysis criterion is to examine concurrent scenarios involving multiple functions. This involves analyzing whether the software correctly handles conflicts arising from different processing operations performed by multiple functions on a single output interface. The specific process is as follows:

[0083] Iterate through all functions to check if two or more functions have the potential for concurrent timing. If so, check if these functions perform output value operations on the same external output interface data, and determine the methods by which these functions perform value operations on that interface data. Iterate through the input interface data of these functions to analyze whether the input interface data values ​​of these functions will cause these functions to perform value operations on the same external output interface data simultaneously, and whether the value operations are different, i.e., analyze the cause of the failure mode. If there is a possibility that functions may perform value operations on the same external output interface data simultaneously, analyze the situations that cause conflicts or contradictions in the value operations on that output interface data, i.e., identify the failure mode. Then, based on the software usage scenario model, determine the impact of software failure. Based on the cause of software failure (multiple functions performing value operations on the same external output interface data simultaneously), propose corresponding control measures and form security requirements (e.g., specify the priority of multiple functions, and if multiple functions occur simultaneously, only the function with the highest priority is allowed to perform value operations on the output interface data).

[0084] In summary, the above are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A fault mode recognition and analysis method driven by usage scenarios and knowledge base, characterized in that, Usage scenario-based robust test design requires the construction of usage scenarios; based on the basic software FMEA analysis criteria of usage scenarios, and with the help of model-driven, data-driven, and ontology theory, to carry out software failure mode and analysis driven by usage scenarios and knowledge base; at the same time, based on the FMEA analysis results, robust test cases covering failure modes are designed; and a mapping relationship is established between basic software FMEA analysis criteria, failure modes, and various usage scenario elements. The scenario- and knowledge-driven basic software FMEA analysis framework specifically consists of: inputting software usage scenarios and a software fault knowledge base. The software usage scenarios include normal usage scenarios such as database management, database querying and operation, as well as abnormal scenarios such as error data scenarios, illegal operation scenarios, and exception handling scenarios. The software fault knowledge base includes FMEA analysis criteria for error data handling, exception handling, and illegal operation handling. The software fault mode and its impact analysis list includes fault causes, fault modes, regulatory impacts, control measures, and robustness requirements.

2. The method as described in claim 1, characterized in that, Based on the software operation process, we construct normal usage scenarios, error data handling scenarios, abnormal situation handling scenarios, illegal operation handling scenarios, and combined scenarios based on usage profiles. Then, using ontology theory methods, we decompose the typical element information in the usage scenarios, including interface data, functional logic, working status, timing constraints, and operation permissions. The method for constructing software use cases based on ontology theory includes the following steps: Step 11: Based on the terminology definition and classification requirements of software system usage scenarios, achieve an accurate understanding of the ontology modeling domain of software usage scenarios; Step 12: Combine the content of normal and abnormal software usage scenarios to establish a usage scenario model based on ontology theory. Step 13: Guided by typical software system usage scenarios, trim and refine various software ontology elements to form a software usage scenario model based on ontology theory, until the constraints of software fault mode identification analysis and robustness testing are met.

3. The method as described in claim 1, characterized in that, Based on the requirements of GJB 900A and GJB / Z 102A standards and typical usage scenario elements, and using historical project fault data, this paper abstracts and refines the illegal access, abnormal interface data, invalid functional logic, concurrent read / write conflicts, process management anomalies, and multi-node access conflicts contained in the fault data, using first-order predicate logic and set theory. This forms standardized, unambiguous general fault modes and fault knowledge data for software FMEA analysis criteria, laying the foundation for robust test case design.

4. The method according to any one of claims 1-3, characterized in that, The specific criteria for software FMEA analysis are as follows: Error data processing analysis criteria: Space allocation anomaly analysis: Analyze and design the software memory space allocation process to confirm whether the software effectively detects and handles fault modes such as allocated space being greater than available space and space allocation failure; Data read / write anomaly analysis: Analyze and design the software's data read / write process to confirm whether the software can effectively detect and handle fault modes such as multiple connections concurrently operating on the same data, writing extremely large data blocks, frequent memory-hard disk data exchange, exceeding disk quotas, and high-concurrency, high-frequency read / write. Data value anomaly analysis: Analyze and design data values ​​to confirm whether the software can effectively detect and handle fault modes such as illegal objects, data values ​​exceeding the valid value range, and data without initial values; Communication transmission anomaly analysis: Analyze and design the communication transmission process between software interfaces to confirm whether the software can effectively detect and handle fault modes such as excessively many-link communication, high-load communication, abnormal interruption of communication links, repeated connection of communication links, and incorrect data frame format. Abnormal timing constraint analysis: Analyze and design the interface timing constraints to confirm whether the software can effectively detect and handle fault modes such as data acquisition period longer than the specified period, data acquisition time later than the specified time, and data acquisition duration longer than the specified duration. Abnormal Situation Handling Analysis Guidelines: Data Maintenance and Backup Anomaly Analysis: Analyze and design the software data maintenance and backup process to confirm whether the software effectively detects and handles failure modes such as interruption during import / export, backup and recovery process, and import / export timeout. Process Management Anomaly Analysis: Analyze and design the software's process management and thread management to confirm whether the software effectively detects and handles fault modes such as continuous process creation, continuous thread creation, memory out-of-bounds access, and illegal pointers; Illegal Judgment Condition Analysis: Analyze and design the functional judgment conditions to confirm whether the software effectively detects and handles fault modes such as judgment conditions changing from true to false or judgment conditions being true repeatedly. Abnormal Branch Path Analysis: Analyze and design different branch paths for each function to confirm whether the software effectively detects and handles fault modes such as unreachable branch paths, simultaneous execution of multiple branch paths, and conflicting or duplicated branch paths; Function Execution Timeout Analysis: Analyze and design the function execution sequence to confirm whether the software effectively detects and handles fault modes such as delayed start, delayed end, and timeout in function scheduling; Function Concurrency Conflict Analysis: Analyze and design the execution conditions and processes of multiple functions to confirm whether the software effectively detects and handles fault modes such as control process conflicts and interface data value conflicts caused by the simultaneous execution of multiple functions. Functional Sequence Anomaly Analysis: This involves analyzing and designing the execution sequence of multiple functions to confirm whether the software effectively detects and handles fault modes such as abnormal operation sequences, abnormal data sequences, and abnormal human behavior sequences among multiple functions. Device call conflict analysis: Analyze and design the devices accessed or called by the function to confirm whether the software can effectively detect and handle fault modes such as data resource conflicts and device control conflicts that occur when multiple functions read data at the same time. Illegal Operation Handling Analysis Criteria: Invalid Access Permission Analysis: Analyze and design software user permissions and their settings to confirm whether the software can effectively detect and handle fault modes such as unauthorized access, no access permissions set, database access prohibited, and read / write permission errors. Abnormal Equipment Status Analysis: Analyze and design the software for operation-related external equipment to confirm whether the software can effectively detect and handle fault modes such as equipment power failure and equipment in initialization state; Illegal Operation Behavior Analysis: Analyze and design the software for personnel operation behavior to confirm whether the software can effectively detect and handle fault modes such as personnel misoperation, incorrect operation, and rapid operation. Invalid operation process analysis: Analyze and design the personnel operation process and activities to confirm whether the software can effectively detect and handle failure modes such as invalid operation, abnormal operation interruption, equipment failure to respond to operation commands, inconsistency with software operation specifications, and execution sequence errors.

5. The method as described in claim 4, characterized in that, Based on the established FMEA analysis guidelines for various basic software, corresponding checklists are developed to form an operational checklist covering various usage scenarios and failure modes. These checklists support basic software designers in checking various usage scenarios and failure modes, identifying potential security risks arising from non-compliance between the basic software analysis and design and the guidelines. The process for checking basic software requirements design based on the compliance checklist is as follows: According to various FMEA analysis guidelines, a comprehensive analysis and check is performed on the requirements design elements in normal software usage scenarios and various abnormal scenarios. If the requirements design elements in the software usage scenarios fully implement the guidelines, then "YES" is entered in the compliance check column. The description section should also describe the relevant content of the analysis criteria. If this criterion does not apply to the design elements of the current use case, fill in N / A in the compliance check column and describe the reason why the criterion is not applicable and the relevant design content that is not applicable in the description column. If the requirement design elements in the use case do not implement this criterion, fill in NO in the compliance check column, and describe the relevant requirement design content that does not implement this criterion in the description column, and conduct further analysis to clarify the possible failure problems caused when the use case does not conform to the analysis criterion.

6. The method as described in claim 5, characterized in that, Based on the usage scenario and analysis criteria, a formal analysis algorithm for software failure modes is adopted, which is based on the usage scenario of the external interface ontology and the corresponding analysis criteria, including the first analysis criterion and the second analysis criterion. The first analytical criterion is to examine the analog input interface data of the software and analyze whether the software has handled the data correctly when the value of the analog input interface data is greater than the upper limit of the boundary value of the value range. The second analysis criterion is to examine the concurrent operation of multiple functions, analyze whether the software has handled the conflicting values ​​caused by multiple functions performing different processing operations on an output interface.

Images