A cascading analysis and simulation verification method for airworthy onboard software requirements

Abstract

The application discloses a kind of cascade analysis and simulation verification method of airworthiness airborne software requirement, belong to airworthiness software requirement engineering technical field.The method includes: the function of system requirement or equipment requirement is collected and is decomposed into software senior requirement;Interface connection is carried out in the same function cluster;Establish the relationship matrix of same level demand and calculate reachable matrix, identify potential influence and loop relationship and handle;Senior requirement is structured and is established demand logic tree, to verify requirement in simulation form;Establish cross-level traceability matrix and construct total traceability matrix, determine upstream and downstream influence;Establish system function relationship matrix, set abnormal detection point to split into series function group for function loop, carry out safety influence analysis according to FDAL highest grade.The application can improve the accuracy of requirement review, reduce the omission rate of change influence analysis, move the requirement verification forward, and ensure the integrity of safety analysis under complex cascade relationship.

Description

Technical Field

[0001] This invention relates to the field of airworthiness software requirements engineering technology, and in particular to a cascade analysis and simulation verification method for airworthiness airborne software requirements. Background Technology

[0002] This invention relates to the field of airworthiness software requirements engineering technology. Airworthiness certification for civil aviation airborne software primarily adopts the RTCA / DO-178B / C standard published by the U.S. Radio Technical Committee on Aeronautics (RTCA). This standard has become the international standard for civil aviation airborne software development, and military aviation airborne software development also refers to this standard. In recent years, with the development of domestically produced large aircraft and the low-altitude economy, more and more domestic manufacturers have entered the civil aviation airborne software field. However, software development according to the DO-178B / C standard requires strict management of the software development process, introducing a large amount of review, examination, testing, and change management work, leading to a significant increase in development costs and a significant extension of the development cycle for various manufacturers. Currently, domestic manufacturers widely use airborne software R&D management tool systems developed for the DO-178B / C standard to manage the software development process. Although such tool systems have basically met the requirements of the DO-178B / C standard, development efficiency has not been significantly improved. Furthermore, according to the requirements of SAE ARP 4754, "Guidelines for the Development of Civil Aircraft and Systems," software requirement changes require a safety assessment at the system level. However, security assessments are based on system functions, while software layer requirements have already decomposed system functions. A certain system function is implemented by multiple software requirements, and there are also coupling relationships between software requirements.

[0003] In this context, identifying the impact of software requirements on security becomes difficult, and achieving security analysis under complex cascading relationships between software requirements is even more challenging. Existing technologies for airworthiness software requirements management have the following shortcomings: First, insufficient structuring and modeling of requirements leads to low efficiency in requirements review; second, existing tools primarily focus on the traceability relationships between upstream and downstream requirements, neglecting the correlation analysis between requirements at the same level; third, the impact analysis after requirement changes lacks reasonable algorithmic support, requiring extensive manual analysis and prone to omissions; fourth, early verification of requirements is insufficient, with much verification work only carried out during the testing phase, resulting in significant iteration costs; fifth, security assessment of software requirements is difficult, and complete security analysis is challenging when there are complex cascading relationships between software requirements.

[0004] In summary, existing airworthiness software requirements management methods have shortcomings in areas such as structured requirements modeling, peer-to-peer requirements correlation analysis, requirements change impact analysis, early requirements verification, and software requirements safety assessment. They have not yet been able to effectively improve the quality and efficiency of the requirements phase while meeting the requirements of the DO-178B / C standard. Therefore, a new method for cascaded analysis and simulation verification of airworthiness airborne software requirements is urgently needed to address the aforementioned technical problems. Summary of the Invention

[0005] The purpose of this invention is to provide a cascade analysis and simulation verification method for airworthy airborne software requirements, in order to solve the following technical problems existing in the prior art: insufficient structuring and modeling of requirements and lack of correlation analysis between requirements at the same level, resulting in low efficiency of requirement review; lack of reasonable algorithm support for the impact analysis after requirement changes, requiring a lot of manual analysis and prone to omissions; insufficient early verification of requirements, with a large amount of requirement verification work only carried out in the testing phase, resulting in large iteration costs; and difficulty in security assessment of software requirements, making it difficult to achieve complete security analysis when the cascade relationship between software requirements is complex.

[0006] To achieve the above objectives, this invention provides a cascade analysis and simulation verification method for airworthy airborne software requirements, comprising: S1. Functionally aggregate system or equipment requirements, group requirements with the same function into the same function cluster, and label the function name and function guarantee level (FDAL); decompose the software high-level requirements according to the function clusters, and label the function name and function guarantee level (FDAL) of the software high-level requirements. The description of the software high-level requirements includes inputs and set outputs. S2. Within the same functional cluster, connect the internal interfaces of the advanced software requirements within the cluster by identifying the inputs and outputs; connect the outputs and inputs of each function accordingly. S3. Establish a relationship matrix between peer requirements, calculate an reachability matrix based on the relationship matrix, and use the reachability matrix to identify potential influences and loop relationships between peer requirements; process the loops. S4. The advanced software requirements are structured and a requirement logic tree is established. The requirements are then verified through simulation by modeling the requirement logic. S5. Establish a traceability matrix between high-level requirements and system requirements or equipment requirements, establish a traceability matrix between high-level requirements and low-level requirements, construct a total traceability matrix, and determine the impact of upstream requirements on downstream requirements and the impact of downstream requirements on upstream requirements. S6. Obtain the mapping relationship between software requirements and system functions; establish a relationship matrix from software requirements to functions, and establish a system function relationship matrix. If a function loop occurs, break the loop; perform an impact analysis on the system function corresponding to the software requirement or the function with the highest function assurance level (FDAL) in the system function group.

[0007] Further, in S1, the inputs and outputs are identified by text and characters, and the text and characters are unique; in S2, unconnected inputs or outputs within the same functional cluster are taken as the inputs or outputs of the corresponding functions, and unconnected inputs or outputs after connection are marked as software function inputs or outputs, including special pure outputs, which are counter outputs; the consistency between the software function inputs or outputs and the software and hardware interface definitions is checked, and if there is a discrepancy, analysis and resolution are performed.

[0008] Furthermore, in S3, the direct relationship in the relationship matrix is ​​defined as a direct input-output relationship between requirements; if the output of the first requirement is the input of the second requirement and the output of the second requirement is the input of the first requirement, then the first requirement and the second requirement are merged or eliminated; the peer requirement reachability matrix is ​​calculated using the peer requirement relationship matrix to find the potential connection relationship between requirements, which is a requirement relationship that is not directly related but indirectly reachable.

[0009] Further, in step S3, the reachability matrix is ​​denoted as P, and a strongly connected matrix Q is calculated based on the reachability matrix P, wherein the strongly connected matrix Q satisfies , where P is the reachability matrix, the transpose of P is represented by the superscript T, and the bitwise AND operator is used to perform a logical AND operation on the corresponding elements of the two matrices; if the element in the i-th row and j-th column of the strongly connected matrix Q is 1 and the element in the j-th row and i-th column are both 1, then the i-th requirement and the j-th requirement are strongly connected, that is, there is the loop relationship, where i and j are the row and column positions in the requirement relationship matrix.

[0010] Furthermore, the loop relationship is that the output of the first high-level requirement becomes the input of the first high-level requirement after a series of high-level requirement processing. This loop relationship is also called an algebraic ring, and it is a strongly connected relationship. Processing the loop includes: processing the loop using a timing method, adding [something] to the output end of the requirement in the loop. Mark to break the algebraic ring.

[0011] Furthermore, in S4, the structured requirements include ID, version, requirement content, interface, requirement logic tree, requirement confirmation data, requirement test cases or procedures, and verification results; the high-level software requirements are visually connected by lines; the requirement logic tree includes logic gate nodes and condition nodes, the logic gate nodes include AND gates, OR gates, and NOT gates, and the condition nodes are Boolean variables; the requirement logic is simulated and analyzed using the SCADE simulation tool.

[0012] Furthermore, in S5, the total traceability matrix M satisfies Where M(H→L) is the traceability matrix from high-level requirements to low-level requirements, and M(S→H) is the traceability matrix from system requirements to high-level requirements; construct matrix C, wherein matrix C satisfies A is a traceability matrix between high-level requirements and system requirements or equipment requirements, B is a traceability matrix between high-level requirements and low-level requirements, and the element in the i-th row and j-th column of C being 1 indicates that the i-th low-level requirement is affected by the j-th system requirement or equipment requirement.

[0013] Further, in S5, constructing the total traceability matrix and calculating the reachability matrix includes: calculating the reachability matrix I through the total traceability matrix; if the element in the i-th row and j-th column of the reachability matrix I is 1, then the i-th demand affects the j-th demand; if the element in the i-th row and j-th column of the transpose of the reachability matrix I is 1, then the j-th demand affects the i-th demand; the transpose of the matrix is ​​represented by the superscript T.

[0014] Furthermore, in step S6, if a software requirement appears in multiple system functions, the software requirement is treated as a common requirement. After removing the common requirement, the software requirement and the system function are mapped to a single function. In the software requirement-function relationship matrix, if the software requirement is related to the system function, it is marked as 1; otherwise, it is marked as 0. In the system function relationship matrix, if there is a direct input-output relationship between functions, it is marked as 1; otherwise, it is marked as 0.

[0015] Furthermore, in S6, if a functional loop occurs, an anomaly detection point is set at at least two functions in the functional loop. The anomaly detection point is reported by the software in the form of a fault code. Any two anomaly detection points are selected to divide the functional loop into group A and group B of connected functions. The impact of software requirements on system functions is divided into three cases: corresponding to a unique system function, corresponding to a group of connected system functions, and corresponding to group A or group B of interrupted loop system functions.

[0016] Compared with the prior art, the present invention has the following beneficial effects: To address the shortcomings of existing tools that primarily focus on tracing upstream and downstream requirements while neglecting the analysis of relationships between peer requirements, this invention establishes a relationship matrix between peer requirements and calculates a reachability matrix based on this matrix. This enables the automatic identification of potential connections between peer requirements. Furthermore, it identifies cyclic relationships (algebraic rings) between peer requirements through logical operations on strongly connected matrices and breaks them down using a time-series method. This approach replaces manual review with an algorithmic model, providing objective evidence for high-level requirements reviews and enabling the early detection of hidden logical conflicts. This helps improve the accuracy of airworthiness software requirements reviews and reduces omissions in manual reviews.

[0017] This invention performs structured processing on high-level software requirements, including ID, version, requirement content, interface, requirement logic tree, requirement confirmation data, requirement test cases or procedures, and verification results. It then employs simulation tools to model and analyze the constructed requirement logic tree. This approach provides principle-based evidence of requirement correctness through simulation, overcoming the shortcomings of traditional reviews that rely solely on expert experience. By moving verification work forward to the requirements phase, it helps reduce iteration costs caused by logical conflicts lingering in the testing phase.

[0018] This invention establishes traceability matrices between system or equipment requirements and higher-level requirements, as well as between higher-level and lower-level requirements, and constructs a total traceability matrix through matrix multiplication. This scheme enables any requirement change at any upstream or downstream node to determine its direct and potential impact on other levels of requirements through matrix operations, providing algorithmic support, helping to reduce the workload of regression testing, and lowering the omission rate in requirement change impact analysis.

[0019] To address the challenge of comprehensive system-level security assessments caused by complex cascading relationships in software requirements, this invention establishes a system function relationship matrix to identify functional loops. It then uses anomaly detection points to segment these loops into sequential functional groups and eliminates common requirements to achieve a single mapping. Based on this, the impact of software requirements on system functions is categorized into three cases: corresponding to a unique system function, corresponding to a sequential group of system functions, and corresponding to a broken loop of system functions (Group A or Group B). Impact analysis is then uniformly performed based on the function with the highest Functional Assurance Level (FDAL) among the corresponding functions or functional groups. This approach helps reduce the workload of security assessments while methodologically ensuring the completeness of system-level security analysis.

[0020] By adding to the output of the demand loop Delayed marking for algebraic ring breaking can solve the non-convergence problem caused by algebraic rings in requirement logic simulation, making requirement logic simulation executable and providing an achievable technical path for early requirement verification. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the requirements model for this invention.

[0022] Figure 2 This is a schematic diagram of the requirements logic tree for this invention.

[0023] Figure 3 This is a schematic diagram of the requirements model for an embodiment of the present invention.

[0024] Figure 4 This is a schematic diagram of the requirements logic tree for an embodiment of the present invention.

[0025] Figure 5 This is a schematic diagram of the algebraic loop interruption and anomaly detection points of the system function of the present invention. Detailed Implementation

[0026] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings.

[0027] Example 1

[0028] This embodiment provides a cascade analysis and simulation verification method for airworthiness airborne software requirements, including the following steps: S1. Functionally group system or equipment requirements, group requirements with the same function into a cluster, and label the function name and function guarantee level (FDAL); decompose the functional clusters to obtain advanced software requirements, and label the advanced software requirements with function names and function guarantee levels (FDAL). The description of the advanced software requirements includes inputs and set outputs.

[0029] S2. Within the same functional cluster, internal interface connections are made for the advanced software requirements within the cluster by identifying the inputs and outputs; the outputs of each function are connected to their corresponding inputs.

[0030] S3. Establish a relationship matrix between peer requirements, calculate an reachability matrix based on the relationship matrix, and use the reachability matrix to identify potential influences and loop relationships between peer requirements; process the loops.

[0031] S4. The advanced software requirements are structured and a requirement logic tree is established. The requirements are then verified through simulation by modeling the requirement logic.

[0032] S5. Establish a traceability matrix between high-level requirements and system requirements or equipment requirements, establish a traceability matrix between high-level requirements and low-level requirements, construct a total traceability matrix, and determine the impact of upstream requirements on downstream requirements and the impact of downstream requirements on upstream requirements.

[0033] S6. Obtain the mapping relationship between software requirements and system functions; establish a relationship matrix from software requirements to functions, and establish a system function relationship matrix. If a function loop occurs, break the loop; perform an impact analysis on the system function corresponding to the software requirement or the function with the highest function assurance level (FDAL) in the system function group.

[0034] In one implementation, in this embodiment, in step S1, the input and output are identified by text and character identifiers, and the text and character identifiers are unique; in step S2, unconnected inputs or outputs within the same functional cluster are taken as the inputs or outputs of the corresponding functions, and unconnected inputs or outputs after connection are marked as software function inputs or outputs, including special pure outputs, which are counter outputs; the consistency between the software function inputs or outputs and the software and hardware interface definitions is checked, and if there is a discrepancy, analysis and resolution are performed.

[0035] As one implementation method, in this embodiment, in step S3, the direct relationship in the relationship matrix is ​​defined as a direct input-output relationship between requirements; if the output of the first requirement is the input of the second requirement and the output of the second requirement is the input of the first requirement, then the first requirement and the second requirement are merged or eliminated; the peer requirement reachability matrix is ​​calculated using the peer requirement relationship matrix to find the potential connection relationship between requirements, and the potential connection relationship is a requirement relationship that is not directly related but indirectly reachable.

[0036] As one implementation, in this embodiment, in step S3, the reachability matrix is ​​denoted as P, and a strongly connected matrix Q is calculated based on the reachability matrix P, wherein the strongly connected matrix Q satisfies , where P is the reachability matrix, the transpose of P is represented by the superscript T, and the bitwise AND operator is used to perform a logical AND operation on the corresponding elements of the two matrices; if the element in the i-th row and j-th column of the strongly connected matrix Q is 1 and the element in the j-th row and i-th column are both 1, then the i-th requirement and the j-th requirement are strongly connected, that is, there is the loop relationship, where i and j are the row and column positions in the requirement relationship matrix.

[0037] In one implementation, in this embodiment, the loop relationship is that the output of the first high-level requirement becomes the input of the first high-level requirement after a series of high-level requirement processing. The loop relationship is also called an algebraic ring, and it is a strongly connected relationship. Processing the loop includes: processing the loop using a timing method, adding [something] to the output end of the requirement in the loop. Mark to break the algebraic ring.

[0038] As one implementation method, in this embodiment, in step S4, the structured requirements include ID, version, requirement content, interface, requirement logic tree, requirement confirmation data, requirement test cases or procedures, and verification results; the high-level software requirements are visually connected by lines; the requirement logic tree includes logic gate nodes and condition nodes, the logic gate nodes include AND gates, OR gates, and NOT gates, and the condition nodes are Boolean variables; the requirement logic is simulated and analyzed using the SCADE simulation tool.

[0039] As one implementation method, in this embodiment, in step S5, the total traceability matrix M satisfies Where M(H→L) is the traceability matrix from high-level requirements to low-level requirements, and M(S→H) is the traceability matrix from system requirements to high-level requirements; construct matrix C, wherein matrix C satisfies A is a traceability matrix between high-level requirements and system requirements or equipment requirements, B is a traceability matrix between high-level requirements and low-level requirements, and the element in the i-th row and j-th column of C being 1 indicates that the i-th low-level requirement is affected by the j-th system requirement or equipment requirement.

[0040] In one implementation, in this embodiment, in step S5, constructing the total traceability matrix and calculating the reachability matrix includes: calculating the reachability matrix I through the total traceability matrix; if the element in the i-th row and j-th column of the reachability matrix I is 1, then the i-th demand affects the j-th demand; if the element in the i-th row and j-th column of the transpose of the reachability matrix I is 1, then the j-th demand affects the i-th demand; the transpose of the matrix is ​​represented by the superscript T.

[0041] As one implementation method, in this embodiment, in step S6, if a software requirement appears in multiple system functions, the software requirement is treated as a common requirement. After removing the common requirement, the software requirement and the system function are mapped to a single value. In the software requirement-to-function relationship matrix, if the software requirement is related to the system function, it is marked as 1; otherwise, it is marked as 0. In the system function relationship matrix, if there is a direct input-output relationship between functions, it is marked as 1; otherwise, it is marked as 0.

[0042] As one implementation method, in this embodiment, in step S6, if a functional loop occurs, an anomaly detection point is set at at least two functions in the functional loop. The anomaly detection point is reported by the software in the form of a fault code. The two anomaly detection points divide the functional loop into group A and group B of connected functions. The impact of software requirements on system functions is divided into three cases: corresponding to a unique system function, corresponding to a group of connected system functions, and corresponding to group A or group B of interrupted loop system functions.

[0043] Example 2

[0044] Based on Example 1, this embodiment provides a more detailed explanation of the specific implementation method of the cascade analysis and simulation verification method for airworthiness airborne software requirements, in conjunction with the accompanying drawings.

[0045] In the actual airworthiness software development process, the system requirements or equipment requirements document is received first, and the requirements recorded therein are grouped according to function. Requirements that achieve the same function are grouped together, and each group is labeled with a function name and a Functional Assurance Level (FDAL). The Functional Assurance Level (FDAL) is divided into five levels: A, B, C, D, and E, according to the DO-178B / C standard.

[0046] For each functional cluster, system or equipment requirements are decomposed into high-level software requirements. Each high-level software requirement is labeled with its corresponding functional name and functional assurance level (FDAL). The description of each high-level software requirement includes the inputs and outputs set by that requirement. Inputs and outputs are identified using a combination of text and characters, for example, input is represented as "flight altitude" and output as "control current". The text and character identifiers are unique throughout the entire requirement set.

[0047] like Figure 3 As shown, Figure 3 This document presents a requirement model for a specific implementation, where functions are grouped according to different Functional Assurance Levels (FDAL). Each functional block includes structured elements such as ID, version, requirement content, interface, requirement logic tree, requirement confirmation data, requirement test cases or procedures, and verification results. In this requirement model, the inputs and outputs of requirements with the same function are connected to form a function grouping module. Input and output connections are established between each functional node through output and input interfaces to complete the connection checks of internal interfaces.

[0048] Figure 3 The "XXX function" in the text is a general placeholder for the function name. In actual application, it is replaced with the specific function name of the airborne software. Different functions may have different function assurance levels (FDAL). Figure 3 yes Figure 1 The application of the general requirements model shown in the specific embodiments will Figure 1 The general structured requirements in the document are grouped into several functional clusters according to different functional guarantee levels (FDAL) and arranged by function. In this embodiment, high-level requirements R1 to R16 are used as examples, and their input-output relationships among peers are expressed by the following peer requirement relationship matrix.

[0049] Specifically, within the same functional cluster, all high-level software requirements within that cluster are traversed, and the inputs and outputs of each requirement are identified. When the output character identifier of one requirement is the same as the input character identifier of another requirement, the output is connected to the input, thereby completing the internal interface connection between requirements within that functional cluster.

[0050] After completing the internal interface connections of each functional cluster, any unconnected inputs or outputs within the same functional cluster are designated as the inputs or outputs of that function. Then, the outputs of each function are connected to their corresponding inputs. Inputs or outputs that are still unconnected after completing the input connections for each function are marked as software function inputs or outputs. Unconnected outputs may include special pure outputs, such as counter outputs. After completing the above marking, the consistency between the software function inputs or outputs and the hardware / software interface definitions is checked. If there is a discrepancy, analysis and resolution are performed.

[0051] like Figure 1 As shown, each high-level requirement is structured, and the high-level requirements are visually connected by lines. A structured requirement includes eight elements: ID, version, requirement content, interface, requirement logic tree, requirement confirmation data, requirement test cases or procedures, and verification results.

[0052] It should be noted that different requirement clusters correspond to different functions and are marked with corresponding function guarantee levels, such as... Figure 3 The three functional blocks are labeled with functional assurance levels FDL B, FDL C, and FDL D, respectively. The ID, version, requirement content, interface, requirement logic tree, requirement confirmation data, requirement test cases or procedures, and verification results shown in each requirement box constitute the unified elements of structured requirements. The specific content of these elements differs between different functional clusters. Functional clusters are connected across functions through unconnected inputs and outputs, thus forming a complete software requirements model.

[0053] This embodiment provides supplementary explanations for the analysis of peer-level demand relationships and loop identification: A peer-level demand relationship matrix is ​​established. If there is a direct input-output relationship between demands, the corresponding value in the matrix is ​​1; otherwise, it is 0. The direct input-output relationship is defined as: the existence of a direct input-output relationship between demands.

[0054] If the established direct relationship matrix shows that the output of high-level requirement A is the input of high-level requirement B, and the output of high-level requirement B is the input of high-level requirement A, then the two requirements will be merged or processed to eliminate this bidirectional direct connection.

[0055] A peer-to-peer demand reachability matrix is ​​calculated using the peer-to-peer demand relationship matrix to identify potential connections between demands. These potential connections are demand relationships that are not directly related but are indirectly reachable. Taking three peer-to-peer higher-level demands HLR-1, HLR-2, and HLR-3 as examples, the rows and columns of their peer-to-peer demand relationship matrix correspond to HLR-1, HLR-2, and HLR-3 respectively. If there is a direct relationship between demands, the corresponding value in the matrix is ​​1; otherwise, it is 0. The element values ​​of this peer-to-peer demand relationship matrix are as follows:

[0056] In the matrix above, the row containing HLR-1 has a 1 only in the column corresponding to HLR-3, the row containing HLR-2 has a 1 only in the column corresponding to HLR-3, and the row containing HLR-3 has a 1 in both the columns corresponding to HLR-1 and HLR-2, with all other positions having a 0. Therefore, HLR-1 and HLR-3 are directly related, as are HLR-2 and HLR-3. While HLR-1 and HLR-2 are not directly related, both are related to HLR-3. Thus, HLR-1 and HLR-2 are indirectly reachable through HLR-3, indicating a potential connection.

[0057] The reachability matrix can be calculated using either the Warshall algorithm or the Tarjan algorithm for strongly connected component analysis. In this specific application, taking high-level requirements R1 to R16 as an example, their direct input-output relationships at the same level are represented by the following peer requirement relationship matrix, and a high-level requirement reachability matrix is ​​established accordingly. This reachability matrix is ​​a 16-order square matrix, with its rows and columns corresponding to R1 to R16 respectively. A number 1 indicates a direct input-output relationship between two corresponding requirements, and a number 0 indicates no direct input-output relationship between two corresponding requirements. The high-level requirement reachability matrix is ​​as follows:

[0058] Using Tarjan's algorithm to perform strong connectivity analysis on the above reachability matrix, all algebraic rings between requirements can be obtained. Among them, R1→R2→R3→R1 and R4→R5→R6→R4 are two three-element algebraic rings, as follows:

[0059] Furthermore, in the same-level demand relationship matrix, R7 and R8, R9 and R10, R11 and R12, R13 and R14, and R15 and R16 are mutually input and output, forming five pairs of bi-element algebraic rings (bidirectional direct connection). These five pairs of bi-element algebraic rings are handled similarly to the three-element algebraic rings mentioned above: two demands can be merged or eliminated according to the bidirectional direct connection, or a Z−1 unit delay marker can be added to the output of the corresponding demand on the loop path to break the algebraic ring, thus enabling the demand logic simulation to converge and become executable.

[0060] Let the reachability matrix be P, and calculate the strongly connected matrix Q based on the reachability matrix P. The strongly connected matrix Q satisfies:

[0061] Wherein, P is the reachable matrix, the transpose of P is represented by the superscript T, and the bitwise AND operator is used to perform a logical AND operation on corresponding elements of the two matrices.

[0062] If the element in the i-th row and j-th column of a strongly connected matrix Q is 1 in both row and j and the element in the i-th column, then advanced requirement i and advanced requirement j are strongly connected, meaning there is a loop relationship. Here, i and j are the row and column positions in the requirement relationship matrix.

[0063] To illustrate the calculation process more clearly, a numerical example is given below. Assume there are three peer requirements HLR-1, HLR-2, and HLR-3, and their relation matrix R is a 3x3 square matrix. An element in the i-th row and j-th column is 1 if the output of HLR-1 is the input of HLR-j, and 0 otherwise. In this example, the output of HLR-1 is the input of HLR-2, and the output of HLR-2 is the input of HLR-3. Therefore, the element in the 1st row and 2nd column, and the 2nd row and 3rd column of the relation matrix R are 1, and all other elements are 0.

[0064] The reachability matrix P is obtained by successively raising the relation matrix R to its first, second, and third powers and then performing a logical OR operation. Calculations show that the elements in the 1st row and 2nd column, 1st row and 3rd column, and 2nd row and 3rd column of the reachability matrix P are 1, while the remaining elements are 0. This indicates that HLR-1 not only directly affects HLR-2 but also indirectly affects HLR-3 through HLR-2.

[0065] By performing a bitwise AND operation on the reachability matrix P and its transpose to calculate the strongly connected matrix Q, we can obtain that all elements in Q are 0, indicating that there is no strongly connected loop relationship between the three requirements.

[0066] Assuming another scenario, if the output of HLR-3 is also the input of HLR-1, meaning the element in the 3rd row and 1st column of the relation matrix R is also 1, then we can calculate that all elements of P are 1 and all elements of Q are also 1, indicating that HLR-1, HLR-2, and HLR-3 are strongly connected and have a loop relationship.

[0067] The loop relationship described is that the output of high-level requirement A, after undergoing a series of high-level requirement processing steps, becomes the input of high-level requirement A again. This loop relationship is also known as an algebraic ring. If a loop relationship occurs, it must be handled using timing methods.

[0068] In practical applications, for the first algebraic ring mentioned above, the input of R1, after being passed through R2 and R3, depends on the output of R1 itself. Therefore, it is necessary to break the algebraic ring by adding an algebraic ring interruption at the output of R3. Note: For the second algebraic ring mentioned above, the input of R4 depends on the output of R4 itself after being passed through R5 and R6. Therefore, it is necessary to break the algebraic ring by adding a step at the output of R6. Mark. The aforementioned This is the unit delay operator in the z-transform, representing a delay of one clock cycle. In the demand logic tree, this is added to the output of the corresponding demand on the loopback path. A node indicates that the output is delayed by one clock cycle before being used as the input for the next requirement, thus breaking the algebraic loop and allowing the requirement logic simulation to converge and become executable. This embodiment uses the SCADE simulation tool to... Figure 3 The requirement logic is simulated and analyzed, and evidence of requirement compliance is provided in the form of requirement principles.

[0069] According to DO-178B / C, high-level requirements reviews need to check the consistency and uniqueness of requirements, ensuring that they do not conflict or become redundant. However, in reality, once the number of high-level requirements reaches a certain level, it becomes impossible to rely on manual reviews to discover all potential problems, ultimately relying on testing, which incurs high iteration costs. This embodiment uses rigorous mathematical methods of relation matrices and reachability matrices to identify the relationships between requirements. This information can serve as both a reference and evidence for reviews, enabling early detection of requirement issues and improving development efficiency.

[0070] like Figure 2 As shown, the requirement logic tree expresses the logical relationship of requirements in a tree structure. The leaf nodes are condition nodes (Boolean variables), and the middle and root nodes are logic gate nodes (AND gate, OR gate, NOT gate). Logical operations are performed on the condition nodes through the logic gate nodes to finally obtain the output result of the requirement.

[0071] like Figure 4 As shown, Figure 4 This demonstrates a typical requirement logic gate structure. Taking the requirement logic tree of a certain control instruction K as an example, the control logic of this high-level requirement is: if the following condition is met, then control instruction K is set to True; otherwise, it is set to False: 1a. A is True, or 1b. B is True; and 2a. C is False, and 2b. D is True, or 3. E is False.

[0072] Figure 4 The code clearly transforms the above logic into a tree-like interconnected structure of AND, OR, NOT gates, and underlying Boolean variables (A, B, C, D, E). On the loop paths of this logic tree, by adding... Delayed marking enables the breaking of algebraic rings.

[0073] Requirements validation data provides support for the correctness of requirements by modeling the logic or requirements of high-level requirements, in the form of simulation, serving as the principle or explanation of the requirements. After completing the timing interruption, combined with... Figure 4 The constructed logic tree was simulated using the SCADE simulation tool. Figure 3 The overall requirement logic is simulated and analyzed to generate principled evidence that meets airworthiness standards. The requirement logic tree is imported into the SCADE simulation tool, various combinations of input conditions are set, the simulation is run, and the output results are observed to see if they meet expectations. The correctness of the requirement logic is verified through simulation, providing principled evidence of the correctness of the requirements in the form of simulation.

[0074] According to DO-178B / C, the objectives of high-level requirements can be demonstrated through review. However, in reality, reviews often struggle to address potential requirement issues, relying solely on individual or organizational experience with limited supporting evidence. This embodiment, through constructing structured requirements, presenting a requirement logic tree, and simulating and verifying the requirement logic, combined with analysis of peer requirement relationships, provides strong support for ensuring the correctness of requirements.

[0075] In this embodiment, a traceability matrix is ​​established between high-level requirements and system requirements or equipment requirements, as well as a traceability matrix between high-level requirements and low-level requirements.

[0076] In this embodiment, the traceability matrix is ​​defined by the direction of influence, that is, the matrix behavior is the demand that is affected, the columns of the matrix are the demands that produce the influence, and a matrix element of 1 indicates that the row demand is affected by the column demand, and a matrix element of 0 indicates that the row demand is not affected by the column demand.

[0077] First, establish a traceability matrix between high-level requirements and system or equipment requirements, denoted as matrix A. Let matrix A be j rows and i columns, with its rows corresponding to HLR-1, HLR-2, ..., HLR-6, ​​... up to HLR-j, and its columns corresponding to SRS-1, SRS-2, ..., SRS-6, ... up to SRS-i. Here, i and j represent the total number of system or equipment requirements and high-level requirements, respectively, and SRS-i and HLR-j represent the i-th system or equipment requirement and the j-th high-level requirement, respectively, with any sequence number. For ease of display, the table below only lists the values ​​of the first 6 rows and 6 columns. The remaining rows and columns between the 6th and last requirements are indicated by ellipses "...". The values ​​at the corresponding positions in the last row (HLR-j) and the last column (SRS-i) are also indicated by "..." and are not listed individually. A matrix element of 1 indicates that the corresponding high-level requirement is affected by the corresponding system or equipment requirement, while 0 indicates that it is not affected. In the first 6 rows and 6 columns listed: HLR-1 has a value of 1 in the corresponding positions of SRS-3, SRS-4, and SRS-6; HLR-2 has a value of 1 in the corresponding positions of SRS-2 and SRS-5; HLR-3 has a value of 1 in the corresponding positions of SRS-1, SRS-2, and SRS-5; HLR-4 has a value of 1 in the corresponding positions of SRS-2, SRS-3, and SRS-6; HLR-5 has a value of 1 in the corresponding positions of SRS-3 and SRS-4; and HLR-6 has a value of 1 in the corresponding positions of SRS-1, SRS-4, and SRS-5. The remaining positions in the first 6 rows and 6 columns are all 0. The element values ​​are as follows:

[0078] Next, establish a traceability matrix between high-level and low-level requirements, denoted as matrix B. Matrix B corresponds to k rows and j columns, with its rows corresponding to LLR-1, ..., LLR-6, ​​... up to LLR-k, and its columns corresponding to HLR-1, ..., HLR-6, ​​... up to HLR-j. Here, k and j represent the total number of low-level and high-level requirements, respectively, and HLR-j and LLR-k represent the j-th high-level requirement and k-th low-level requirement, respectively, with any sequence number. For ease of display, the table below only lists the values ​​of the first 6 rows and 6 columns. The remaining rows and columns between the 6th and last requirements are indicated by ellipses "...". The values ​​at the corresponding positions of the last row LLR-k and the last column HLR-j are also indicated by "..." and are not listed individually. A matrix element of 1 indicates that the corresponding low-level requirement is affected by the corresponding high-level requirement, and 0 indicates that it is not affected. In the first 6 rows and 6 columns listed: LLR-1 is 1 in the corresponding positions of HLR-3, HLR-4, and HLR-6; LLR-2 is 1 in the corresponding positions of HLR-2 and HLR-5; LLR-3 is 1 in the corresponding positions of HLR-1, HLR-2, and HLR-5; LLR-4 is 1 in the corresponding positions of HLR-2, HLR-3, and HLR-6; LLR-5 is 1 in the corresponding positions of HLR-3 and HLR-4; and LLR-6 is 1 in the corresponding positions of HLR-1, HLR-4, and HLR-5. The remaining positions in the first 6 rows and 6 columns are all 0. The element values ​​are as follows:

[0079] After establishing the two types of traceability matrices mentioned above, a total traceability matrix M is constructed. The total traceability matrix M is divided into three levels: system requirements or equipment requirements, high-level requirements, and low-level requirements. Its block structure is as follows:

[0080] In this matrix, the transposes of A and B are located in their respective blocks, and the remaining blocks are zero matrices.

[0081] In practical applications, a traceability matrix M(S→H) is established for equipment requirements (labeled S1 to S16) and advanced requirements (labeled H1 to H16). This matrix is ​​a 16-order square matrix. According to the definition in this specification, "the matrix's behavior represents the affected requirements, and the columns represent the requirements that have an impact," the rows correspond to H1 to H16, and the columns correspond to S1 to S16. A matrix element of 1 indicates that the advanced requirement corresponding to the row is affected by the equipment requirement corresponding to the column, and a matrix element of 0 indicates that the advanced requirement corresponding to the row is not affected by the equipment requirement corresponding to the column. The traceability matrix M(S→H) is as follows:

[0082] Next, establish a traceability matrix M(H→L) for high-level requirements (labeled H1 to H16) and low-level requirements (labeled L1 to L16). This matrix is ​​a 16-order square matrix. According to the definition in this specification, "the matrix's behavior represents the requirements that are affected, and the columns represent the requirements that generate the effect," the rows correspond to L1 to L16, and the columns correspond to H1 to H16. A matrix element of 1 indicates that the low-level requirement corresponding to the row is affected by the high-level requirement corresponding to the column, and a matrix element of 0 indicates that the low-level requirement corresponding to the row is not affected by the high-level requirement corresponding to the column. The traceability matrix M(H→L) is as follows:

[0083] Construct the total tracing matrix M(S→L), which is obtained by multiplying matrix M(H→L) and matrix M(S→H), i.e.:

[0084] Where M(H→L) is the traceability matrix from high-level requirements to low-level requirements, and M(S→H) is the traceability matrix from system requirements to high-level requirements.

[0085] The above matrix multiplication is bridged through the intermediate layer high-level requirements (HLR): the rows of matrix M(S→H) and the columns of matrix M(H→L) both correspond to high-level requirements, and the two are aligned in the high-level requirement dimension, so that the system requirements are traced back to the low-level requirements level by level through the high-level requirements.

[0086] To illustrate the calculation process more clearly, a numerical example is given below. Assume there are 2 system requirements SRS-1 and SRS-2, 3 high-level requirements HLR-1, HLR-2, and HLR-3, and 2 low-level requirements LLR-1 and LLR-2.

[0087] The traceability matrix M(S→H) from system requirements to higher-level requirements is 3 rows and 2 columns. Rows correspond to higher-level requirements, and columns correspond to system requirements. An element in the i-th row and j-th column that is 1 indicates that the i-th higher-level requirement is affected by the j-th system requirement. In this example, HLR-1 is only affected by SRS-1, so the elements in the first row are 1 and 0 respectively; HLR-2 is affected by both SRS-1 and SRS-2, so both elements in the second row are 1; HLR-3 is only affected by SRS-2, so the elements in the third row are 0 and 1 respectively.

[0088] The traceability matrix M(H→L) from high-level requirements to low-level requirements is 2 rows and 3 columns, with rows corresponding to low-level requirements and columns corresponding to high-level requirements. In this example, LLR-1 is affected by HLR-1 and HLR-3, so the elements in the first row are 1, 0, and 1 respectively; LLR-2 is affected by HLR-2 and HLR-3, so the elements in the second row are 0, 1, and 1 respectively.

[0089] Multiplying matrix M(H→L) with matrix M(S→H) yields a total traceability matrix M(S→L) with 2 rows and 2 columns, where the two elements in the first and second rows are both 1.

[0090] This indicates that LLR-1 is affected by SRS-1 and SRS-2, and LLR-2 is also affected by SRS-1 and SRS-2.

[0091] In addition, a matrix C can be constructed that satisfies A is a traceability matrix between high-level requirements and system requirements or equipment requirements, B is a traceability matrix between high-level requirements and low-level requirements, and the element in the i-th row and j-th column of C being 1 indicates that the i-th low-level requirement is affected by the j-th system requirement or equipment requirement.

[0092] This master traceability matrix enables bidirectional automated analysis: when a high-level requirement changes (denoted as i), it can automatically determine the affected low-level requirement number j and the corresponding equipment requirement k. Specifically, when the high-level requirement with number i changes, it affects the low-level requirement row number j corresponding to all elements of the i-th column of matrix M(H→L) that are 1, and also affects the equipment requirement column number k corresponding to all elements of the i-th row of matrix M(S→H); when the low-level requirement j changes, it affects the high-level requirement column number i corresponding to all elements of the j-th row of matrix M(H→L) that are 1, and further affects the equipment requirement k corresponding to the element 1 in the master traceability matrix.

[0093] The reachability matrix I is calculated using the overall traceability matrix. If the element in the i-th row and j-th column of reachability matrix I is 1, then the i-th requirement affects the j-th requirement; if the element in the i-th row and j-th column of the transpose of reachability matrix I is 1, then the j-th requirement affects the i-th requirement. The transpose of the matrix is ​​denoted by the superscript T. When a requirement changes, the reachability matrix can quickly determine the direct and potential impacts of this change on other requirements, reducing manual analysis workload and lowering the omission rate.

[0094] Change management is the most labor-intensive part of configuration management in the DO-178B / C process, and impact analysis of change management is the most labor-intensive part of change management. When there are many requirements, impact analysis becomes extremely difficult, as it's hard to identify all impacts, often relying on regression testing and resulting in repeated iterations. The traceability and impact analysis method provided in this embodiment can comprehensively and deeply identify the direct and potential impacts of a change in a requirement on other requirements, helping to reduce iteration costs.

[0095] In this embodiment, the mapping relationship between software requirements and system functions is obtained from the interface connection step. If a software requirement appears in multiple system functions, it is treated as a common requirement. After removing the common requirement, a single mapping is achieved between the software requirement and the system function.

[0096] Establish a relationship matrix from software requirements to functions, as well as a system function relationship matrix. Referencing the methods used in peer requirement relationship analysis, conduct a system function relationship analysis.

[0097] In practical applications, a reachability matrix for system functions is established. This system function reachability matrix is ​​a 14-order square matrix, with its rows and columns corresponding to system functions SF1 to SF14 respectively. A matrix element of 1 indicates that there is a direct input-output relationship between two corresponding system functions, while a matrix element of 0 indicates that there is no direct input-output relationship. The system function reachability matrix is ​​as follows:

[0098] Similarly, using the Tarjan algorithm to perform strong connectivity analysis on the above reachability matrix, the analysis reveals the following functional algebraic ring of the system:

[0099] like Figure 5 As shown, the system's functional algebraic loop is broken by inserting detection point 1 and detection point 2 (corresponding to the fault code throw positions of anomaly detection) on the loop path. Detection point 1 and detection point 2 divide the functional algebraic loop into group A and group B functions. Figure 5 Taking the five system functions SF1 to SF5 as an example, detection points 1 and 2 are set at SF2 and SF4 respectively. Group A includes SF1, SF5, and SF4, and Group B includes SF2 and SF3. Abnormal detection points are reported by the software in the form of fault codes. When a functional abnormality is detected, the software outputs the corresponding fault code for easy location and troubleshooting. For functional algebraic loops containing more system functions, at least two system functions are selected on the loopback path to set abnormal detection points, dividing the functional algebraic loop into two groups of cascaded functions, A and B.

[0100] At the same time, the system function reachability matrix can also distinguish between pure serial function paths without loops and bidirectional direct-connected function pairs: each function on a pure serial function path is transmitted unidirectionally and does not form a loop, and can be directly used as a serial function group, for example, SF8 acts unidirectionally on SF7; while SF9 and SF10, SF11 and SF12, SF13 and SF14 are input and output to each other, forming three pairs of two-element function loops, which need to be separated or interrupted by setting an abnormal detection point according to the aforementioned function loop interruption rules.

[0101] Based on the system functions or functional groups obtained from the above analysis, combined with the functional traceability impact analysis, the impact of software requirements at any level on system functions can be analyzed.

[0102] Ultimately, the impact of software requirements on system functionality is categorized into three cases: Group A or Group B, which corresponds to a unique system function, a set of system functions in series, and a broken loop system function.

[0103] By combining the aforementioned traceability matrix, software requirements are mapped to Group A, Group B, or a specific, unique system function. The highest FDL (Fast Impact Level) within each mapped group is rigorously extracted. Impact analysis is then performed on the function with the highest FDL corresponding to the software requirement or within the function group, resulting in a final security impact analysis report. This approach reduces the workload of analyzing the impact of software requirements on system security while ensuring the completeness of the security analysis methodologically.

[0104] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. It should be noted that any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A cascaded analysis and simulation verification method for airworthy airborne software requirements, characterized in that, include: S1. Functionally group system or equipment requirements, group requirements with the same function into the same function cluster, and mark the function name and function assurance level (FDAL). The software high-level requirements are obtained by decomposing the functional clusters, and the functional names and functional assurance levels (FDAL) of the software high-level requirements are marked. The description of the software high-level requirements includes inputs and set outputs. S2. Within the same functional cluster, the high-level software requirements within the cluster are internally interfaced by identifying the input and the output, and the outputs of each function are correspondingly connected to the inputs. S3. Establish a relationship matrix between peer requirements, calculate an reachability matrix based on the relationship matrix, and use the reachability matrix to identify potential influences and loop relationships between peer requirements. S4. The advanced software requirements are structured and a requirement logic tree is established. The requirements are then verified through simulation by modeling the requirement logic. S5. Establish a traceability matrix between high-level requirements and system requirements or equipment requirements, establish a traceability matrix between high-level requirements and low-level requirements, construct a total traceability matrix, and determine the impact of upstream requirements on downstream requirements and the impact of downstream requirements on upstream requirements. S6. Obtain the mapping relationship between software requirements and system functions; Establish a relationship matrix from software requirements to functions, and establish a system function relationship matrix. If a function loop occurs, the function loop will be broken. Impact analysis is performed on the system functions or system function groups that correspond to the software requirements and have the highest FDL (Feature Assurance Level) for the functions.

2. The cascaded analysis and simulation verification method for airworthy airborne software requirements according to claim 1, characterized in that, In step S1, the input and the output are identified by text and character identifiers, and the text and character identifiers are unique. In S2, unconnected inputs or outputs within the same functional cluster are taken as inputs or outputs of the corresponding functions, and unconnected inputs or outputs after connection are marked as software function inputs or outputs. The unconnected outputs after connection include special pure outputs, and the special pure outputs are counter outputs. Check the consistency between the software function inputs or outputs and the software and hardware interface definitions. If there is a discrepancy, analyze and resolve it.

3. The cascaded analysis and simulation verification method for airworthy airborne software requirements according to claim 1, characterized in that, In S3, the direct relationship in the relationship matrix is ​​defined as a direct input-output relationship between requirements; If the output of the first requirement is the input of the second requirement and the output of the second requirement is the input of the first requirement, then the first requirement and the second requirement are merged or eliminated. The peer demand reachability matrix is ​​calculated using the peer demand relationship matrix to identify potential connections between demands. These potential connections are demand relationships that are not directly related but are indirectly reachable.

4. The cascaded analysis and simulation verification method for airworthy airborne software requirements according to claim 1, characterized in that, In step S3, the reachability matrix is ​​denoted as P, and a strongly connected matrix Q is calculated based on the reachability matrix P. The strongly connected matrix Q satisfies , where P is the reachable matrix, the transpose of P is represented by the superscript T, and the bitwise AND operator is used to perform a logical AND operation on corresponding elements of the two matrices; If the element in the i-th row and j-th column of the strongly connected matrix Q is 1 and the element in the j-th row and i-th column is 1, then the i-th demand and the j-th demand are strongly connected, that is, there is the loop relationship, where i and j are the row and column positions in the demand relationship matrix.

5. The cascaded analysis and simulation verification method for airworthy airborne software requirements according to claim 1, characterized in that, The loop relationship is that the output of the first high-level requirement becomes the input of the first high-level requirement after being processed by a series of high-level requirements. The loop relationship is also called an algebraic ring, and the loop relationship is a strongly connected relationship. The processing of the loop includes: processing the loop using a timing method, and adding a required output terminal in the loop. Mark to break the algebraic ring.

6. The cascaded analysis and simulation verification method for airworthy airborne software requirements according to claim 1, characterized in that, In S4, the structured requirements include ID, version, requirement content, interface, requirement logic tree, requirement confirmation data, requirement test cases or procedures, and verification results. The advanced software requirements are visually connected via lines. The requirement logic tree includes logic gate nodes and condition nodes. The logic gate nodes include AND gates, OR gates, and NOT gates. The condition nodes are Boolean variables. The required logic was simulated and analyzed using the SCADE simulation tool.

7. The cascaded analysis and simulation verification method for airworthy airborne software requirements according to claim 1, characterized in that, In S5, the total traceability matrix M satisfies , where M(H→L) is the traceability matrix from high-level requirements to low-level requirements, and M(S→H) is the traceability matrix from system requirements to high-level requirements; Construct a matrix C such that the matrix C satisfies A is a traceability matrix between high-level requirements and system requirements or equipment requirements, B is a traceability matrix between high-level requirements and low-level requirements, and the element in the i-th row and j-th column of C being 1 indicates that the i-th low-level requirement is affected by the j-th system requirement or equipment requirement.

8. The cascaded analysis and simulation verification method for airworthy airborne software requirements according to claim 1, characterized in that, In step S5, constructing the total traceability matrix and calculating the reachability matrix includes: calculating the reachability matrix I through the total traceability matrix; if the element in the i-th row and j-th column of the reachability matrix I is 1, then the i-th demand affects the j-th demand; if the element in the i-th row and j-th column of the transpose of the reachability matrix I is 1, then the j-th demand affects the i-th demand; the transpose of the matrix is ​​represented by the superscript T.

9. The cascaded analysis and simulation verification method for airworthy airborne software requirements according to claim 1, characterized in that, In step S6, if a software requirement appears in multiple system functions, the software requirement is treated as a common requirement. After removing the common requirement, the software requirement and the system function are mapped to a single function. In the software requirement-to-function relationship matrix, if a software requirement is related to a system function, it is marked as 1; otherwise, it is marked as 0. In the system function relationship matrix, if there is a direct input-output relationship between functions, it is marked as 1; otherwise, it is marked as 0.

10. The cascaded analysis and simulation verification method for airworthy airborne software requirements according to claim 1, characterized in that, In S6, if a functional loop occurs, an abnormal detection point is set at at least two functions in the functional loop. The abnormal detection point is reported by the software in the form of a fault code. Any two abnormal detection points are selected to divide the functional loop into group A and group B for series connection. The impact of software requirements on system functionality can be categorized into three cases: Group A or Group B, which correspond to a unique system function, a set of system functions connected in series, and a broken loop system function.

Images