Safety verification method for embedded software requirement by means of failure data

Abstract

The application provides a kind of embedded software requirement security verification method by means of failure data, which includes: establishing software requirement model, formalizing model description of software requirement, carrying out the patternization processing of failure data, explicitly failure data mode information, establishing the mapping relationship between software requirement model and failure data, carrying out the security verification of software requirement model, obtaining software requirement security verification result, the elements of the software requirement model include function input interface, function output interface and function processing process.The application is driven by failure data and security verification rules, and focuses on the key information that can easily cause engine control software to run failure, which can significantly improve work efficiency and quality, and ensure that potential failure modes and system hazards in software requirements are fully identified.

Description

Technical Field

[0001] This invention belongs to the field of embedded software security technology, and in particular, it is a method for verifying the security requirements of embedded software by utilizing failure data. Background Technology

[0002] With the widespread adoption of computer technology, the proportion of system hazards caused by software failures is gradually increasing, resulting in significant economic and resource losses. High security and high reliability have become general requirements for software development.

[0003] Statistical analysis of field software security incidents reveals that the vast majority of incidents are related to software requirement issues, namely insufficient or inaccurate requirements, while a small number are caused by code errors. Therefore, the quality of software requirements has become a key factor affecting software security levels. Scientifically and systematically utilizing critical software security failure data during software development to form reusable failure data experience can provide data support and guidance for the security verification of software requirements. This can effectively prevent the recurrence of software security failures or system hazards, significantly improve the efficiency of software requirement security verification, and ensure a steady improvement in software security levels. Currently, software requirement security verification technology is the most effective means of ensuring software security. Therefore, it is urgent and necessary to extract several basic failure data points and seek an embedded software requirement security verification method that leverages failure data to significantly improve work efficiency and quality, ensuring the full identification of potential failure modes and system hazards in software requirements. Summary of the Invention

[0004] This invention addresses the shortcomings of existing technologies by proposing an embedded software requirement safety verification method utilizing failure data. The method includes establishing a software requirement model, formally describing the software requirements, processing failure data in a pattern-based manner, clarifying failure data pattern information, establishing a mapping relationship between the software requirement model and the failure data, conducting safety verification of the software requirement model, and obtaining the software requirement safety verification result. The elements of the software requirement model include functional input interfaces, functional output interfaces, and functional processing procedures. This invention, driven by failure data and safety verification rules, focuses on key information that can easily lead to engine control software malfunctions, significantly improving work efficiency and quality, and ensuring the full identification of potential failure modes and system hazards in software requirements.

[0005] This invention provides a method for verifying the security requirements of embedded software using failure data, comprising the following steps:

[0006] S1. Establish a software requirements model, formally describing the software requirements. The elements of the software requirements model include functional input interfaces, functional output interfaces, and functional processing procedures. Define the software requirements model as a functional set F = {F1, ..., F2}. i ,...,F n}, where n is a constant; F i Let the i-th function be defined as:

[0007] F i ={(F iName ,f i )|f i ∈F iI ×F iP →F iO}={F iName ,F iI ,F iO ,F iP}

[0008] Among them, F iName F represents the function name of the i-th function; iI F represents the set of function input interfaces for the i-th function; iO F represents the set of function output interfaces for the i-th function; iP f represents the functional processing procedure of the i-th function; i This represents the functional description of the i-th function;

[0009] S2. Perform pattern processing on the failure data and clarify the failure data pattern information: Organize and summarize all failure data, assign hierarchical guidance words to each failure data, and clarify the failure data pattern information of the failure data; the guidance words include first-level guidance words and second-level guidance words;

[0010] S21. Associate the failure data with first-level guiding words: classify the failure data according to the failure type into functional input interface failure data, functional processing failure data, and functional output interface failure data; the first-level guiding words include functional input interface failure, functional processing failure, and functional output interface failure.

[0011] S22. Associate the second-level guide word with the failure data to clarify the failure data pattern information:

[0012] S3. Establish a mapping relationship between the software requirements model and failure data, wherein the mapping relationship includes a first mapping relationship and a second mapping relationship;

[0013] S31. Establish a first mapping relationship between the elements of the software requirements model and the first guiding words of the failure data. The first mapping relationship includes the functional input interface to functional input interface failure mapping, the functional processing process to functional processing process failure mapping, and the functional output interface to functional output interface failure mapping.

[0014] S32. Establish a second mapping relationship between the elements of the software requirement model and the second guide words of the failure data, wherein the second mapping relationship is that the specific information of the elements of the software requirement model is mapped to the second guide words of the failure data respectively;

[0015] S4. Conduct security verification of the software requirement model: Based on the mapping relationship between the software requirement model and the failure data, design security verification rules and perform security verification on the elements of the software requirement model.

[0016] S5. Obtain the software requirement security verification result: Check whether all elements of the software requirement model meet the analysis and verification coverage requirements, that is, the analysis and verification coverage of the functional input interface reaches 100%, the analysis and verification coverage of the functional output interface reaches 100%, and the analysis and verification coverage of the functional processing reaches 100%. If so, the security verification of the software requirement model is completed, and the security verification result of the software requirement model is output; otherwise, proceed to step S4. The analysis and verification coverage reaching 100% means that all elements of the software requirement model have been verified and analyzed one by one for all the failure data.

[0017] Furthermore, the security verification rule in step S4 specifically includes the following steps:

[0018] S41. Select any unverified element of the software requirement model as the element to be verified, and verify one by one whether all the failure data and the element to be verified have the mapping relationship. If so, the failure data is taken as the first failure data and step S42 is executed; otherwise, the failure data is taken as the second failure data and step S45 is executed.

[0019] S42. Check whether the element to be verified provides a corresponding first processing measure for the failure data pattern information contained in the first failure data. If so, the security verification of the software requirement model for the first failure data is passed and step S44 is executed; otherwise, the security verification of the software requirement model for the first failure data is failed and step S43 is executed.

[0020] S43. Provide a corresponding second processing measure for the element to be verified in response to the failure data pattern information contained in the first failure data. The software requirement model passes the security verification of the first failure data and executes step S44.

[0021] S44. Analyze the correctness and sufficiency of the processing measures, which include the first processing measure and the second processing measure; analyze whether the first processing measure or the second processing measure can effectively and sufficiently control the safety-critical failure problem contained in the failure data. If yes, proceed to step S5; otherwise, the software requirement model is corrected to fail the security verification of the first failure data and step S43 is executed.

[0022] S45. Perform supplementary analysis and verification on the elements of the software requirement model: Based on the mapping relationship between the software requirement model and the failure data, analyze one by one whether the second failure data is applicable to the element to be verified. If so, use the second failure data as the first failure data and execute step S42; otherwise, record in the security verification result of the software requirement model that the second failure data is not applicable to the element to be verified and execute step S5.

[0023] Preferably, step S22 specifically includes the following steps:

[0024] S221. When the first-level guiding word associated with the failure data is the failure of the functional input interface, the second-level guiding word includes timing failure, data failure, communication failure, redundancy voting failure, fault diagnosis failure, fault handling failure, and a first custom word.

[0025] S222. When the first-level guiding word associated with the failure data is the failure of the functional processing process, the second-level guiding word includes timing failure, data failure, logic failure, channel switching failure, fault diagnosis failure, fault handling failure, signal acquisition failure, signal processing failure, timing control failure, algorithm failure, closed-loop control failure, functional interaction failure, and state transition failure.

[0026] S223. When the first-level guide word associated with the failure data is the failure of the function output interface, the second-level guide word includes timing failure, data failure, communication failure, redundancy voting failure, fault diagnosis failure, fault handling failure, and second custom word.

[0027] Preferably, the set of function input interfaces F for the i-th function in step S1 is... iI Represented as:

[0028] F iI ={FI irange ,FI iO,FI inam}

[0029] Among them, FI irange F represents iI The range of values ​​and FI irange ={Up I Low I Up I F represents iI The upper limit, Low I F represents iI The lower limit of FI; iO F represents iI After F iP Mapped set of function output interfaces; FI inam This represents the name of the function input interface for the i-th function;

[0030] The set of function output interfaces F of the i-th function iO Represented as:

[0031] F iO ={FO irange ,FO iI ,FO inam}

[0032] Among them, FO irange F represents iO The range and FO irange ={Up O Low O Up O F represents iO The upper limit; Low O F represents iO The lower limit value; FO iI F represents iO After F iP Mapped set of functional input interfaces; FO inam This represents the name of the function output interface for the i-th function;

[0033] The functional processing F of the i-th function iP Represented as:

[0034] F iP ={P iI ,P iT ,P iO ,P iC ,P iJ}

[0035] Among them, P iI F represents i For F iI Processing function; P iO F representsi For F iO Processing function; P iT P represents the set of transition conditions between functional processing functions; iJ F represents i The set of decision nodes; P iC This represents the constraint information of each element in the functional processing model; the constraints include logical constraints and temporal constraints. The logical constraints include AND, OR, NOT, XOR, mapping relationship, equivalent to, less than, greater than, equal to, subordinate to, mutually exclusive, combination, priority to, less than or equal to, and greater than or equal to; the temporal constraints include preorder relationship, postorder relationship, concurrency relationship, delay relationship, and timing relationship.

[0036] Preferably, the failure data mode information of the functional input interface failure data in step S221 is as follows:

[0037] FI Mode0 : Failure data of the timing-failed function input interface, i.e., FI Mode0 ={Leading, Lagging, Abnormal Signal Period};

[0038] FI Mode1 The function input interface for data failure is called FI (Firmware). Mode1 ={Exceeding the upper limit, exceeding the lower limit, data remains unchanged};

[0039] FI Mode2 : Communication failure input interface failure data, i.e., FI Mode2 = {No data received, interface data source sensor malfunction, connection circuit open};

[0040] FI Mode3 : The input interface for the redundancy voting function is invalid, i.e., FI Mode3 = {Without a redundancy voting strategy, all redundancy interface data are abnormal};

[0041] FI Mode4 : Fault diagnosis failure of the function input interface failure data, i.e., FI Mode4 ={Extremum diagnosis not performed, filtering diagnosis not performed, slope diagnosis not performed};

[0042] FI Mode5 : Fault handling failure of the function input interface failure data, i.e., FI Mode5 ={Fault results were not processed after fault diagnosis; fault handling measures are only effective for certain software functions; different fault handling measures conflict with each other};

[0043] FI Mode6 The first custom function input interface failed;

[0044] The failure data mode information of the functional processing failure data in step S222 is as follows:

[0045] FF Mode0 : Failure data in the timing failure process of the functional handling procedure, i.e., FF Mode0 ={The timing of the start of the operation is advanced, and the timing of the end of the operation is advanced};

[0046] FF Mode1 The data invalidation process handles invalid data, i.e., FF. Mode1 = {Divide by 0 during the solution process, result exceeds the lower limit, result exceeds the upper limit};

[0047] FF Mode2 : Failure data in the logical failure handling process, i.e., FF Mode2 = {Logical constraint condition is incorrectly judged, logical constraint condition is always false, input domain that cannot be covered by logical branch};

[0048] FF Mode3 : Failure data in the function handling process of channel switching failure, i.e., FF Mode3 ={Current channel successfully switched to another channel, channel switching timed out};

[0049] FF Mode4 Fault diagnosis failure processing data, i.e., FF Mode4 ={false alarms during fault diagnosis, frequent alarms during fault diagnosis};

[0050] FF Mode5 Fault handling failure data, i.e., FF. Mode5 ={The same fault phenomenon has conflicting handling strategies in different functions, and the fault handling strategy adopted by the current function causes other functions to fail};

[0051] FF Mode6 : Failure data in the signal acquisition failure processing procedure, i.e., FF Mode6 = {Communication protocol failure, interface signal acquisition time ahead of schedule, missing interface data};

[0052] FF Mode7 Signal processing failure: Failure data in the signal processing process, i.e., FF. Mode7 = {The interface signal was not debouncing / smoothing, and the correctness of the interface data values ​​was not checked};

[0053] FF Mode8 Failure data in the timing control function processing, i.e., FF Mode8 ={The entry conditions for the control process are not met, and the preceding control process has not been completed / cannot be completed};

[0054] FF Mode9 The algorithm failure process handles failure data, i.e., FF. Mode9 ={The sampling algorithm's calculation results did not meet expectations, and the interpolation algorithm's calculation results did not meet expectations};

[0055] FF Mode10 Failure data in the closed-loop control failure process, i.e., FF Mode10 ={The control algorithm based on the control object model is inaccurate, and the sampling period of the discrete control loop does not meet the control requirements};

[0056] FF Mode11 : Failure data in the functional processing procedure due to functional interaction failure, i.e., FF Mode11 = {Whether the processing logic of a function is duplicated with the processing logic of other functions, without considering the priority between different software functions in the same working state};

[0057] FF Mode12 Failure data in the functional processing of state transition failure, i.e., FF Mode12 ={Critical data was not stored or protected before the software switched to the power-off state, and the values ​​or settings of the function output interfaces changed under different states};

[0058] The failure data mode information of the functional output interface failure data in step S223 is as follows:

[0059] FO Mode0 : Failure data of the timing-failed function output interface, i.e., FO Mode0 ={Leading, Lagging, Abnormal Signal Period};

[0060] FO Mode1 The function outputs failed data, i.e., FO. Mode1 ={Exceeding the upper limit, exceeding the lower limit, data remains unchanged};

[0061] FO Mode2 The function output interface failed due to communication failure, i.e., FO. Mode2 ={Destination device of interface output failure, interface output buffer failure, destination device of interface output feedback too fast or too slow};

[0062] FO Mode3 The function output interface for redundancy voting has failed, i.e., FO. Mode3 ={The output data values ​​of the two redundant interfaces are significantly different, and the two redundant interfaces continue to output simultaneously};

[0063] FO Mode4 Fault diagnosis failure output interface failure data, i.e., FOMode4 ={Output line BIT fault detection not performed, output interface dual redundancy inconsistency fault detection not performed, output out-of-limit data fault detection};

[0064] FO Mode5 Fault handling failure output interface failure data, i.e., FO Mode5 ={Fault results were not processed after fault diagnosis; fault handling measures are only effective for certain software functions; different fault handling measures conflict with each other};

[0065] FO Mode6 The second custom function output interface failed.

[0066] Preferably, in step S21, the failure data of the function input interface is associated with the failure of the function input interface, the failure data of the function processing process is associated with the failure of the function processing process, and the failure data of the function output interface is associated with the failure of the function output interface.

[0067] Compared with the prior art, the technical effects of the present invention are as follows:

[0068] 1. This invention proposes an embedded software requirement security verification method using failure data. The core of the proposed method is to extract several basic failure data from the perspectives of functional input interfaces, output interfaces, functional processing procedures, and system hazards. Based on this, software requirement security verification rules are formed. Based on the basic failure data and security verification rules, a software requirement security verification method is proposed. This software requirement security verification method, based on accurate basic failure data and multiple security verifications, can ensure the accuracy of the final verification result.

[0069] 2. The present invention proposes an embedded software requirement security verification method based on failure data. The proposed method is based on failure data and security verification rules, and focuses on considering key information that is prone to causing engine control software failure, such as dynamic logical relationships between software functions, software and hardware interaction relationships, functional input and output interfaces, and working state transitions. It can significantly improve work efficiency and quality, and ensure that potential failure modes and system hazards in software requirements are fully identified. Attached Figure Description

[0070] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings.

[0071] Figure 1 This is a flowchart of the embedded software requirement security verification method based on failure data of the present invention;

[0072] Figure 2This is a schematic diagram of the functional input / output interface model of a control system software in a specific embodiment of the present invention;

[0073] Figure 3 This is a schematic diagram of the functional processing model established in a specific embodiment of the present invention. Detailed Implementation

[0074] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0075] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0076] Figure 1 The present invention illustrates an embedded software requirement security verification method using failure data, the method comprising the following steps:

[0077] S1. Establish a software requirements model, formally describing the software requirements. The elements of the software requirements model include functional input interfaces, functional output interfaces, and functional processing procedures; define the software requirements model as a set of functions F = {F1,...,F2}. i ,...,F n}, where n is a constant; F i Let the i-th function be defined as:

[0078] F i ={(F iName ,f i )|f i ∈F iI ×F iP →F iO}={F iName ,F iI ,F iO ,F iP}

[0079] Among them, F iName F represents the function name of the i-th function; iI F represents the set of function input interfaces for the i-th function; iO F represents the set of function output interfaces for the i-th function; iP f represents the functional processing procedure of the i-th function; i This represents the functional description of the i-th function.

[0080] The set of function input interfaces F for the i-th functioniI Represented as:

[0081] F iI ={FI irange ,FI iO ,FI inam}

[0082] Among them, FI irange F represents iI The range of values ​​and FI irange ={Up I Low I Up I F represents iI The upper limit, Low I F represents iI The lower limit of FI; iO F represents iI After F iP Mapped set of function output interfaces; FI inam This represents the name of the input interface for the i-th function.

[0083] The set of function output interfaces F for the i-th function iO Represented as:

[0084] F iO ={FO irange ,FO iI ,FO inam}

[0085] Among them, FO irange F represents iO The range and FO irange ={Up O Low O Up O F represents iO The upper limit; Low O F represents iO The lower limit value; FO iI F represents iO After F iP Mapped set of functional input interfaces; FO inam This represents the name of the function output interface for the i-th function.

[0086] The functional processing procedure F of the i-th function iP Represented as:

[0087] F iP ={P iI ,P iT ,P iO ,P iC ,P iJ}

[0088] Among them, P iI F represents i For F iI Processing function; P iO F represents i For F iO Processing function; P iT P represents the set of transition conditions between functional processing functions; iJ F represents i The set of decision nodes; P iC This represents the constraint information of each element in the functional processing model; constraints include logical constraints and temporal constraints. Logical constraints include AND, OR, NOT, XOR, mapping relationships, equivalent to, less than, greater than, equal to, subordinate to, mutually exclusive, combination, priority to, less than or equal to, and greater than or equal to; temporal constraints include preorder relationships, postorder relationships, concurrency relationships, delay relationships, and timing relationships.

[0089] In one specific embodiment, a certain type of control system consists of a cockpit, indicator lights, mechanical devices, and an electrical system. The control system software receives control command signals from a host computer, processes them through corresponding functions, and outputs control current to external devices to achieve the control function. The control software includes two similar redundancies (i.e., channel A control software and channel B control software), one channel serving as the main control software and the other in a hot backup state. When the main control channel software malfunctions, it can automatically switch to the hot backup channel software.

[0090] For the control system software, we conducted software requirement security verification, identified potential failure modes in the software interface requirements, analyzed the causes and effects of the failure modes, and determined the handling measures for the failure modes.

[0091] The control system software includes information on external interconnection devices and functional input / output interfaces (including interface type, interface name, interface data, etc.), such as... Figure 2 As shown; a functional processing model is established based on software requirements. Taking a certain control function as an example, the established functional processing model is demonstrated: Figure 3 As shown.

[0092] Based on the external interface diagram and software requirements of a certain type of control software, clarify the functional input interface model information of the certain type of control software as follows:

[0093] Table 1 shows the functional output interface model information of a certain type of control software, and Table 2 shows the information of the output interface model.

[0094]

[0095] Table 1

[0096]

[0097]

[0098] Table 2

[0099] S2. Perform pattern processing on the failure data and clarify the failure data pattern information: Organize and summarize all failure data, assign hierarchical guidance words to each failure data, and clarify the failure data pattern information of the failure data; the guidance words include first-level guidance words and second-level guidance words.

[0100] S21. Associating failure data with first-level guiding terms: Classify failure data by failure type into functional input interface failure data, functional processing failure data, and functional output interface failure data; the first-level guiding terms include functional input interface failure, functional processing failure, and functional output interface failure; associate functional input interface failure data with functional input interface failure, functional processing failure data with functional processing failure, and functional output interface failure data with functional output interface failure.

[0101] S22. Associate the second-level guide words for the failed data to clarify the failed data pattern information.

[0102] S221. When the first-level guiding term associated with the failure data is the failure of the functional input interface, the second-level guiding term includes timing failure, data failure, communication failure, redundancy voting failure, fault diagnosis failure, fault handling failure, and the first custom term.

[0103] The failure data mode information for the functional input interface failure data in step S221 is as follows:

[0104] FI Mode0 : Failure data of the timing-failed function input interface, i.e., FI Mode0 ={Leading, Lagging, Abnormal Signal Period};

[0105] FI Mode1 The function input interface for data failure is called FI (Firmware). Mode1 ={Exceeding the upper limit, exceeding the lower limit, data remains unchanged};

[0106] FI Mode2 : Communication failure input interface failure data, i.e., FI Mode2 = {No data received, interface data source sensor malfunction, connection circuit open};

[0107] FI Mode3 : The input interface for the redundancy voting function is invalid, i.e., FI Mode3 = {Without a redundancy voting strategy, all redundancy interface data are abnormal};

[0108] FIMode4 : Fault diagnosis failure of the function input interface failure data, i.e., FI Mode4 ={Extremum diagnosis not performed, filtering diagnosis not performed, slope diagnosis not performed};

[0109] FI Mode5 : Fault handling failure of the function input interface failure data, i.e., FI Mode5 ={Fault results were not processed after fault diagnosis; fault handling measures are only effective for certain software functions; different fault handling measures conflict with each other};

[0110] FI Mode6 The first custom function input interface failed.

[0111] S222. When the first-level guiding term associated with the failure data is a functional processing failure, the second-level guiding terms include timing failure, data failure, logic failure, channel switching failure, fault diagnosis failure, fault handling failure, signal acquisition failure, signal processing failure, timing control failure, algorithm failure, closed-loop control failure, functional interaction failure, and state transition failure.

[0112] The failure data mode information for the functional processing failure data in step S222 is as follows:

[0113] FF Mode0 : Failure data in the timing failure process of the functional handling procedure, i.e., FF Mode0 ={The timing of the start of the operation is advanced, and the timing of the end of the operation is advanced};

[0114] FF Mode1 The data invalidation process handles invalid data, i.e., FF. Mode1 = {Divide by 0 during the solution process, result exceeds the lower limit, result exceeds the upper limit};

[0115] FF Mode2 : Failure data in the logical failure handling process, i.e., FF Mode2 = {Logical constraint condition is incorrectly judged, logical constraint condition is always false, input domain that cannot be covered by logical branch};

[0116] FF Mode3 : Failure data in the function handling process of channel switching failure, i.e., FF Mode3 ={Current channel successfully switched to another channel, channel switching timed out};

[0117] FF Mode4 Fault diagnosis failure processing data, i.e., FF Mode4 ={false alarms during fault diagnosis, frequent alarms during fault diagnosis};

[0118] FFMode5 Fault handling failure data, i.e., FF. Mode5 ={The same fault phenomenon has conflicting handling strategies in different functions, and the fault handling strategy adopted by the current function causes other functions to fail};

[0119] FF Mode6 : Failure data in the signal acquisition failure processing procedure, i.e., FF Mode6 = {Communication protocol failure, interface signal acquisition time ahead of schedule, missing interface data};

[0120] FF Mode7 Signal processing failure: Failure data in the signal processing process, i.e., FF. Mode7 = {The interface signal was not debouncing / smoothing, and the correctness of the interface data values ​​was not checked};

[0121] FF Mode8 Failure data in the timing control function processing, i.e., FF Mode8 ={The entry conditions for the control process are not met, and the preceding control process has not been completed / cannot be completed};

[0122] FF Mode9 The algorithm failure process handles failure data, i.e., FF. Mode9 ={The sampling algorithm's calculation results did not meet expectations, and the interpolation algorithm's calculation results did not meet expectations};

[0123] FF Mode10 Failure data in the closed-loop control failure process, i.e., FF Mode10 ={The control algorithm based on the control object model is inaccurate, and the sampling period of the discrete control loop does not meet the control requirements};

[0124] FF Mode11 : Failure data in the functional processing procedure due to functional interaction failure, i.e., FF Mode11 = {Whether the processing logic of a function is duplicated with the processing logic of other functions, without considering the priority between different software functions in the same working state};

[0125] FF Mode12 Failure data in the functional processing of state transition failure, i.e., FF Mode12 ={Critical data was not stored or protected before the software switched to the power-off state, and the values ​​or settings of the function output interfaces changed under different states}.

[0126] S223. When the first-level guiding term associated with the failed data is the failure of the functional output interface, the second-level guiding term includes timing failure, data failure, communication failure, redundancy voting failure, fault diagnosis failure, fault handling failure, and second custom term.

[0127] The failure data mode information for the functional output interface failure data in step S223 is as follows:

[0128] FO Mode0 : Failure data of the timing-failed function output interface, i.e., FO Mode0 ={Leading, Lagging, Abnormal Signal Period};

[0129] FO Mode1 The function outputs failed data, i.e., FO. Mode1 ={Exceeding the upper limit, exceeding the lower limit, data remains unchanged};

[0130] FO Mode2 The function output interface failed due to communication failure, i.e., FO. Mode2 ={Destination device of interface output failure, interface output buffer failure, destination device of interface output feedback too fast or too slow};

[0131] FO Mode3 The function output interface for redundancy voting has failed, i.e., FO. Mode3 ={The output data values ​​of the two redundant interfaces are significantly different, and the two redundant interfaces continue to output simultaneously};

[0132] FO Mode4 Fault diagnosis failure output interface failure data, i.e., FO Mode4 ={Output line BIT fault detection not performed, output interface dual redundancy inconsistency fault detection not performed, output out-of-limit data fault detection};

[0133] FO Mode5 Fault handling failure output interface failure data, i.e., FO Mode5 ={Fault results were not processed after fault diagnosis; fault handling measures are only effective for certain software functions; different fault handling measures conflict with each other};

[0134] FO Mode6 The second custom function output interface failed.

[0135] In one specific embodiment, examples of failure data patterning results are shown in Table 3.

[0136]

[0137]

[0138] Table 3

[0139] S3. Establish a mapping relationship between the software requirements model and failure data. The mapping relationship includes a first mapping relationship and a second mapping relationship.

[0140] S31. Establish a first mapping relationship between the elements of the software requirements model and the first guiding term of the failure data. The first mapping relationship includes the failure mapping from the functional input interface to the functional input interface, the failure mapping from the functional processing process to the functional processing process, and the failure mapping from the functional output interface to the functional output interface.

[0141] S32. Establish a second mapping relationship between the elements of the software requirement model and the second guide words of the failure data. The second mapping relationship is that the specific information of the elements of the software requirement model is mapped to the second guide words of the failure data respectively.

[0142] In one specific embodiment, an algorithm for mapping the software requirement model to failure data is established, and some results are shown in Table 4.

[0143]

[0144]

[0145] Table 4

[0146] S4. Conduct security verification of the software requirement model: Based on the mapping relationship between the software requirement model and failure data, design security verification rules and perform security verification on the elements of the software requirement model.

[0147] The designed security verification rules are as follows:

[0148] S41. Select any unverified element in the software requirements model as the element to be verified, and verify one by one whether there is a mapping relationship between all the failed data and the element to be verified. If so, take the failed data as the first failed data and execute step S42; otherwise, take the failed data as the second failed data and execute step S45.

[0149] S42. Check whether the element to be verified provides a corresponding first processing measure for the failure data mode information contained in the first failure data. If so, the security verification of the software requirement model for the first failure data is passed and step S44 is executed; otherwise, the security verification of the software requirement model for the first failure data is not passed and step S43 is executed.

[0150] In one specific embodiment, some results of the security verification of the software requirements model are shown in Table 5.

[0151]

[0152]

[0153] Table 5

[0154] S43. Provide corresponding second processing measures for the failure data pattern information contained in the first failure data for the element to be verified. The software requirement model passes the security verification of the first failure data and executes step S44.

[0155] In one specific embodiment, a second processing measure is provided for the element to be verified in response to the failure data pattern information contained in the first failure data, and some results are shown in Table 6.

[0156]

[0157] Table 6

[0158] S44. Analyze the correctness and sufficiency of the handling measures, which include the first handling measures and the second handling measures; analyze whether the first handling measures or the second handling measures can effectively and sufficiently control the safety-critical failure issues contained in the failure data. If so, proceed to step S5; otherwise, the software requirements model is corrected to fail the safety verification of the first failure data and step S43 is executed.

[0159] In one specific embodiment, the correctness and adequacy of the analysis and treatment measures are illustrated in Table 7.

[0160]

[0161]

[0162] Table 7

[0163] S45. Perform supplementary analysis and verification on the elements of the software requirement model: Based on the mapping relationship between the software requirement model and the failure data, analyze whether the second failure data is applicable to the element to be verified one by one. If so, use the second failure data as the first failure data and execute step S42; otherwise, record in the security verification result of the software requirement model that the second failure data is not applicable to the element to be verified and execute step S5.

[0164] In one specific embodiment, some results of supplementary analysis and verification of the elements of the software requirements model are given as follows:

[0165] As shown in Table 8.

[0166]

[0167] Table 8

[0168] S5. Obtain the software requirement security verification results: Check whether all elements of the software requirement model meet the analysis and verification coverage requirements, that is, the analysis and verification coverage of the functional input interface reaches 100%, the analysis and verification coverage of the functional output interface reaches 100%, and the analysis and verification coverage of the functional processing reaches 100%. If so, the security verification of the software requirement model is completed, and the security verification results of the software requirement model are output; otherwise, proceed to step S4. An analysis and verification coverage of 100% means that all elements of the software requirement model have been verified and analyzed one by one for all failure data.

[0169] This invention presents an embedded software requirement safety verification method utilizing failure data. The core of this method is to extract fundamental failure data from functional input interfaces, output interfaces, functional processing procedures, and system hazards. Based on this, software requirement safety verification rules are formed. A software requirement safety verification method is proposed based on the fundamental failure data and safety verification rules. Driven by failure data and safety verification rules, this method focuses on key information that can easily lead to engine control software failures, such as dynamic logical relationships between software functions, hardware-software interaction relationships, functional input / output interfaces, and operational state transitions. This significantly improves work efficiency and quality, ensuring the full identification of potential failure modes and system hazards in software requirements.

[0170] Finally, it should be noted that the above embodiments are for illustration only and not for limiting the technical solutions of the present invention. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the present invention without departing from the spirit and scope of the present invention. Any modifications or partial substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A method for verifying the security of embedded software requirements using failure data, characterized in that, It includes the following steps: S1. Establish a software requirements model, formally describing the software requirements. The elements of the software requirements model include functional input interfaces, functional output interfaces, and functional processing procedures; define the software requirements model as a set of functions. where n is a constant; Let the i-th function be defined as: ； in, This represents the function name of the i-th function; This represents the set of function input interfaces for the i-th function; This represents the set of function output interfaces for the i-th function; This represents the functional processing procedure of the i-th function; This represents the functional description of the i-th function; S2. Perform pattern processing on the failure data and clarify the failure data pattern information: Organize and summarize all failure data, assign hierarchical guidance words to each failure data, and clarify the failure data pattern information; the guidance words include first-level guidance words and second-level guidance words. This step specifically includes the following sub-steps: S21. Associating first-level guiding words with failure data: The failure data is classified into functional input interface failure data, functional processing failure data, and functional output interface failure data according to the failure type; The first-level guiding words include functional input interface failure, functional processing failure, and functional output interface failure. S22. Associate the second-level guide words with the failure data to clarify the failure data mode information, including at least: timing failure, data failure, logic failure, channel switching failure, fault diagnosis failure, fault handling failure, signal acquisition failure, signal processing failure, timing control failure, algorithm failure, closed-loop control failure, functional interaction failure, and state transition failure. S3. Establish a mapping relationship between the software requirements model and failure data, wherein the mapping relationship includes a first mapping relationship and a second mapping relationship; S31. Establish a first mapping relationship between the elements of the software requirements model and the first guiding words of the failure data. The first mapping relationship includes the functional input interface to functional input interface failure mapping, the functional processing process to functional processing process failure mapping, and the functional output interface to functional output interface failure mapping. S32. Establish a second mapping relationship between the elements of the software requirement model and the second guide words of the failure data, wherein the second mapping relationship is a mapping of the specific information of the elements of the software requirement model to the second guide words of the failure data; S4. Conduct security verification of the software requirement model: Based on the mapping relationship between the software requirement model and the failure data, obtain security verification rules and perform security verification on the elements of the software requirement model. S41. Select any unverified element of the software requirement model as the element to be verified, and verify one by one whether all the failure data and the element to be verified have the mapping relationship. If so, the failure data is taken as the first failure data and step S42 is executed; otherwise, the failure data is taken as the second failure data and step S45 is executed. S42. Check whether the element to be verified provides a corresponding first processing measure for the failure data pattern information contained in the first failure data. If so, the security verification of the software requirement model for the first failure data is passed and step S44 is executed; otherwise, the security verification of the software requirement model for the first failure data is failed and step S43 is executed. S43. Provide a corresponding second processing measure for the element to be verified in response to the failure data pattern information contained in the first failure data. The software requirement model passes the security verification of the first failure data and executes step S44. S44. Analyze the correctness and sufficiency of the processing measures, which include the first processing measure and the second processing measure; analyze whether the first processing measure or the second processing measure can effectively and sufficiently control the safety-critical failure problem contained in the failure data. If yes, proceed to step S5; otherwise, the software requirement model is corrected to fail the security verification of the first failure data and step S43 is executed. S45. Perform supplementary analysis and verification on the elements of the software requirement model: Based on the mapping relationship between the software requirement model and the failure data, analyze one by one whether the second failure data is applicable to the element to be verified. If so, use the second failure data as the first failure data and execute step S42; otherwise, record in the security verification result of the software requirement model that the second failure data is not applicable to the element to be verified and execute step S5. S5. Obtain the software requirement security verification result: Check whether all elements of the software requirement model meet the analysis and verification coverage requirements, that is, the analysis and verification coverage of the functional input interface reaches 100%, the analysis and verification coverage of the functional output interface reaches 100%, and the analysis and verification coverage of the functional processing reaches 100%. If so, the security verification of the software requirement model is completed, and the security verification result of the software requirement model is output; otherwise, repeat step S4. A 100% analysis and verification coverage means that all elements of the software requirement model have been verified and analyzed one by one for all failure data.

2. The embedded software requirement security verification method using failure data according to claim 1, characterized in that, Step S22 specifically includes the following sub-steps: S221. When the first-level guiding word associated with the failure data is the failure of the functional input interface, the second-level guiding word includes timing failure, data failure, communication failure, redundancy voting failure, fault diagnosis failure, fault handling failure, and a first custom word. S222. When the first-level guiding word associated with the failure data is the failure of the functional processing process, the second-level guiding word includes timing failure, data failure, logic failure, channel switching failure, fault diagnosis failure, fault handling failure, signal acquisition failure, signal processing failure, timing control failure, algorithm failure, closed-loop control failure, functional interaction failure, and state transition failure. S223. When the first-level guide word associated with the failure data is the failure of the function output interface, the second-level guide word includes timing failure, data failure, communication failure, redundancy voting failure, fault diagnosis failure, fault handling failure, and second custom word.

3. The embedded software requirement security verification method using failure data according to claim 1, characterized in that, The set of function input interfaces for the i-th function in step S1 Represented as: ； in, express range and , express The upper limit, express The lower limit value; express go through The set of mapped function output interfaces; This represents the name of the function input interface for the i-th function; The set of function output interfaces of the i-th function Represented as: ； in, express range and , express The upper limit; express The lower limit value; express go through The mapped set of functional input interfaces; This represents the name of the function output interface for the i-th function; The functional processing procedure of the i-th function Represented as: ； in, express for The processing function; express for The processing function; This represents the set of transition conditions between functional processing functions; express The set of decision nodes; This represents the constraint information of each element in the functional processing model; the constraints include logical constraints and temporal constraints. The logical constraints include AND, OR, NOT, XOR, mapping relationship, equivalent to, less than, greater than, equal to, subordinate to, mutually exclusive, combination, priority to, less than or equal to, and greater than or equal to; the temporal constraints include preorder relationship, postorder relationship, concurrency relationship, delay relationship, and timing relationship.

4. The embedded software requirement security verification method using failure data according to claim 2, characterized in that, The failure data mode information of the functional input interface failure data in step S221 is as follows: FI Mode0 : Functional input interface failure data due to timing failure, FI Mode0 ={Leading, Lagging, Abnormal Signal Period}; FI Mode1 : Input interface for data failure, FI Mode1 ={Data exceeds upper limit, data exceeds lower limit, data remains unchanged}; FI Mode2 : Communication failure function input interface failure data, FI Mode2 ={No data received, interface data source sensor malfunction, connection circuit open}; FI Mode3 : The input interface for the redundancy voting function has failed, FI Mode3 ={Without a redundancy voting strategy, all redundancy interface data are abnormal}; FI Mode4 : Fault diagnosis failure of the function input interface failure data, FI Mode4 ={Extremum diagnosis not performed, filtering diagnosis not performed, slope diagnosis not performed}; FI Mode5 : Fault handling failure function input interface failure data, FI Mode5 ={Fault results were not processed after fault diagnosis; fault handling measures were only effective for certain software functions; and different fault handling measures conflicted}; FI Mode6 The first custom function input interface failed; The failure data mode information of the functional processing failure data in step S222 is as follows: FF Mode0 : Failure data in the timing failure handling process, FF Mode0 ={The timing of starting the operation is advanced, and the timing of ending the operation is advanced}; FF Mode1 The data invalidation function handles invalid data, FF Mode1 ={Divide by 0 during the solution process, the solution result exceeds the lower limit, and the solution result exceeds the upper limit}; FF Mode2 : Failure data in the logical failure handling process, FF Mode2 ={Logical constraint condition judgment error, logical constraint condition is always false, input domain that cannot be covered by logical branch}; FF Mode3 : Failure data in the function handling process of channel switching failure, FF Mode3 ={The current channel successfully switched to another channel, but the channel switching timed out}; FF Mode4 Fault diagnosis failure processing failure data, FF Mode4 ={False alarms in fault diagnosis, frequent alarms in fault diagnosis}; FF Mode5 Fault handling failure process failure data, FF Mode5 ={The same fault phenomenon causes conflicting handling strategies in different functions, and the fault handling strategy adopted by the current function causes other functions to fail}; FF Mode6 : Failure data in the signal acquisition failure processing procedure, FF Mode6 ={Communication protocol failure, interface signal acquisition time ahead of schedule, missing interface data}; FF Mode7 Signal processing failure: Failure data during signal processing, FF Mode7 ={The interface signals were not debouncing / smoothing, and the correctness of the interface data values ​​was not checked}; FF Mode8 : Failure data in the timing control failure process, FF Mode8 ={The entry conditions for the control process are not met, and the preceding control process is incomplete or cannot be completed}; FF Mode9 The algorithm failure processing steps and failure data, FF Mode9 ={The sampling algorithm's calculation results did not meet expectations, and the interpolation algorithm's calculation results did not meet expectations}; FF Mode10 Failure data in the closed-loop control failure process, FF Mode10 ={The control algorithm based on the control object model is inaccurate, and the sampling period of the discrete control loop does not meet the control requirements}; FF Mode11 : Failure data in the functional processing of interactive failures, FF Mode11 ={Whether the processing logic of a function is duplicated with the processing logic of other functions, without considering the priority between different software functions in the same working state}; FF Mode12 Failure data in the state transition failure handling process, FF Mode12 ={Critical data was not stored or protected before the software switched to the power-off state, and the values ​​or settings of the function output interfaces changed under different states}; The failure data mode information of the functional output interface failure data in step S223 is as follows: FO Mode0 : Failure data of the timing failure function output interface, FO Mode0 ={Leading, Lagging, Abnormal Signal Period}; FO Mode1 The function outputs failed data (FO) via the data failure output interface. Mode1 ={Data exceeds upper limit, data exceeds lower limit, data remains unchanged}; FO Mode2 : Communication failure output interface failure data, FO Mode2 ={Destination device failure at interface output, interface output buffer failure, or interface output destination device feedback being too fast or too slow}; FO Mode3 The redundancy voting function has failed, resulting in the output interface failure data (FO). Mode3 ={The output data values ​​of the two redundant interfaces are significantly different, and the two redundant interfaces continue to output simultaneously}; FO Mode4 Fault diagnosis failure output interface failure data, FO Mode4 ={Output line BIT fault detection not performed, output interface dual redundancy inconsistency fault detection not performed, output out-of-limit data fault detection}; FO Mode5 Fault handling failure output interface failure data, FO Mode5 ={Fault results were not processed after fault diagnosis; fault handling measures were only effective for certain software functions; and different fault handling measures conflicted}; FO Mode6 The second custom function output interface failed.

5. The embedded software requirement security verification method using failure data according to claim 1, characterized in that, In step S21, the failure data of the function input interface is associated with the failure of the function input interface, the failure data of the function processing process is associated with the failure of the function processing process, and the failure data of the function output interface is associated with the failure of the function output interface.

Images