Civil aircraft requirement-oriented numerical control system control software evidence chain development method

Abstract

The invention discloses a civil aircraft requirement-oriented numerical control system control software evidence chain development method. The method comprises the steps of developing and identifying software requirements, establishing bidirectional traceability of the requirements, developing requirement attributes of the software, deriving feedback evaluation of the requirements, reviewing the requirements, and forming review instructions and review conclusions. According to the method, engineering implementation steps of software demand evidence chain development are clarified, the requirements of DO-178C for software development process activities are implemented, and guidance is provided for civil aircraft numerical control system software evidence chain development; a'verification method 'and'verification consideration' are established, the understanding and implementation effect of a demand developer on the demand are transmitted to verification personnel, and the verification personnel are helped to improve the accuracy and sufficiency of case verification; and carrying out peer-to-peer review of demand-by-demand and check-by-check items and forming a review description and a review conclusion, so that the deviation condition of the demand to the DO-178C target can be fully detected, and the achievement of the DO-178C target is ensured.

Description

Technical Field

[0001] The present invention relates to the field of control of aeroengine numerical control systems, and particularly to a method for developing an evidence chain of control software for a numerical control system meeting civil aircraft requirements. Background Art

[0002] As a high-safety critical software, the control software of an aeroengine FADEC system is crucial for the safe operation of the aeroengine and the safe flight of the aircraft. DO-178C is a standard document for the development of airborne software in the civil aviation field. This standard ensures software safety through strict management of the software development process. For the airborne software development process, DO-178C defines the process activity requirements and objectives of the software development process, but lacks guidance on specific development methods and the organization of evidence chains. Currently, there is no specific method guidance on how to develop an airborne software evidence chain meeting the requirements of DO-178C, resulting in numerous difficulties in the engineering practice process. Therefore, it is necessary to propose a method for developing a software evidence chain meeting civil aircraft requirements to provide more specific and detailed practical guidance for the development process activities of civil aircraft software. Summary of the Invention

[0003] Objective of the Invention: The objective of the present invention is to provide a project review method and system based on the requirements of the NQMS system.

[0004] Technical Solution: The method for developing an evidence chain of control software for a numerical control system meeting civil aircraft requirements according to the present invention includes the following steps:

[0005] (1) Develop and identify software requirements;

[0006] (2) Establish two-way traceability of requirements;

[0007] (3) Develop the requirement attributes of the software;

[0008] (4) Derive and evaluate the feedback of requirements;

[0009] (5) Conduct a requirements review to form a review description and a review conclusion.

[0010] Further, step (1) includes developing software requirements based on the system requirements assigned to the software and the results of system safety impact analysis, and defining software-derived requirements; identifying the software-derived requirements and the software requirements decomposed from the system requirements, and recording the identification as a requirement attribute.

[0011] Further, the software requirements decomposed from the system requirements are identified as R, and the software-derived requirements are identified as R-derived, and are recorded in the requirement attribute.

[0012] Further, step (2) includes establishing corresponding traceability based on the decomposition relationship between software requirements and system requirements. When establishing two-way traceability between software requirements and system requirements, if it is found that there are system requirements not undertaken by software requirements or system requirements not fully covered by software requirements, then return to step (1) to supplement relevant requirements; if it is found that there are incorrect or missing identification of software-derived requirements, then return to step (1) to iterate the identification of derived requirements.

[0013] Further, the requirement attributes in step (3) include security requirements, which are used to identify whether the requirement has security impacts; requirement decomposition description, which is used to explain the basis for decomposing software requirements; derivation reason, which is used to explain the derivation basis or design consideration of derived requirements; derivation impact analysis, which describes the implementation effect of derived requirements from the perspective of system functions and is used to assist system personnel and security personnel in quickly understanding derived requirements; derivation impact analysis, which describes the implementation effect of derived requirements from the perspective of system functions and is used to assist system personnel and security personnel in quickly understanding derived requirements; verification method, which is used to explain the verification method to be adopted for this requirement and indicate the verifiability of the requirement; verification consideration, which describes the suggestions of requirement developers on the verification objectives or concerns of this requirement and is used to assist verification personnel in understanding requirements and more accurately designing test cases.

[0014] Further, step (3) includes:

[0015] (3.1) Identify software security requirements and mark them in the security requirement attributes;

[0016] (3.2) Compile the requirement decomposition description attributes according to the formed traceability matrix, and elaborate on the corresponding relationship between the requirements of software requirements and system requirements; if it is found during the compilation of this attribute that the requirements of software requirements exceed the system requirements and are not marked as derived requirements, then it is necessary to return to (3.1) to supplement the derivation mark.

[0017] Further, the software security requirements in step (3.1) include: software requirements decomposed from system security requirements need to be marked as software security requirements; requirements with security impacts in software-derived requirements need to be marked as software security requirements.

[0018] Further, step (4) includes sorting out and forming a list of feedback and evaluation of derived requirements based on the derived requirements developed in step (1) and the derivation reason and derivation impact analysis attributes compiled in step (3), and transmitting it to the system and system security processes.

[0019] Further, step (4) includes:

[0020] System personnel and system security personnel evaluate the rationality of derived requirements item by item and write evaluation descriptions and conclusions;

[0021] System personnel and system security personnel will feedback the evaluation results to the software requirements process after the evaluation is completed;

[0022] Software requirements personnel complete the iterative development of software requirements according to the evaluation opinions, and re-execute the derived requirements feedback evaluation activity until all derived requirements pass the evaluation.

[0023] Further, the step (5) includes establishing a software requirements baseline based on each element of the software requirements formed in steps (1) to (4), including requirement text, traceability, requirement attributes, and derived evaluation conclusions; conducting a peer review of software requirements for this requirements baseline; the peer review checklist is set with reference to Table A-3 of DO-178C, and the software requirements peer review forms a review description and review conclusion item by item for each requirement.

[0024] Beneficial effects: Compared with the prior art, the present invention has the following remarkable advantages: The present invention clarifies the engineering implementation steps of the development of the software requirements evidence chain, implements the requirements for software development process activities in DO-178C, and provides guidance for the development of the civil aircraft CNC system software evidence chain; establishes the attribute of "requirement decomposition description" to elaborate on the origin of software requirements in detail, improves the compliance of software requirements with system requirements, and facilitates the reference of peer review experts for requirements; establishes the attributes of "derivation reason" and "derivation impact analysis" and uses them as materials for the feedback evaluation of derived requirements, helping system and security personnel quickly understand the impact and necessity of derived requirements and making accurate judgments; establishes "verification method" and "verification consideration" to transfer the understanding and implementation effect of requirements developers for requirements to verification personnel, helping verification personnel improve the accuracy and sufficiency of verification cases; conducts a peer review item by item for each requirement and forms a review description and review conclusion, which can fully detect the deviation of requirements from the DO-178C objectives and ensure the achievement of the DO-178C objectives. Description of the Drawings

[0025] Figure 1 is a flowchart of the present invention. Detailed Embodiment

[0026] The technical solution of the present invention will be further described below with reference to the drawings.

[0027] As Figure 1 shown, the specific steps of this method are as follows:

[0028] Step 1: Develop and identify software requirements.

[0029] According to the system requirements assigned to the software and the results of the system security impact analysis, in comparison with the software requirement standards, the "structured analysis" method is used to develop itemized software requirements; while decomposing the system requirements, it is necessary to define the software derived requirements based on the software implementation considerations, such as further refining the system requirements or adding implementation constraints;

[0030] Mark software requirements that are completely decomposed from system requirements as "R", mark software-derived requirements as "R-derived", and record them in the "Is it a requirement" attribute;

[0031] Step 2: Establish two-way traceability of requirements.

[0032] According to the decomposition relationship between software requirements and system requirements, establish corresponding traceability to ensure that all conditions and requirements of software requirements are traceable to the corresponding system requirements, and at the same time ensure that all conditions and requirements of system requirements are undertaken by software requirements;

[0033] While establishing two-way traceability between software requirements and system requirements, if it is found that there are system requirements that are not taken over by software requirements, or system requirements are not fully covered by software requirements, it is necessary to return to step 1 to supplement the relevant requirements; if it is found that the software derived requirements are incorrectly identified or missed, it is necessary to return to step 1 to iterate the identification of derived requirements;

[0034] The traceability relationship between software requirements and system requirements is presented in the form of a traceability matrix as shown in Table 1;

[0035]

[0036] Step 3: Develop the required attributes of the software, as follows:

[0037] Identify software security requirements and mark them in the "Security Requirements" attribute. Software security requirements include: 1) Software requirements decomposed from system security requirements must be marked as software security requirements; 2) Requirements with security impacts in software derived requirements must be marked as software security requirements. The "Security Requirements" attribute uses "yes" and "no" to distinguish between software security requirements and non-software security requirements;

[0038] Prepare the "Requirement Decomposition Description" attribute based on the traceability matrix formed in step 2. In this attribute, the corresponding relationship between the software requirements and the system requirements is explained in detail; if it is found during the preparation of this attribute that the software requirements exceed the system requirements and are not marked as derived requirements, it is necessary to return to step 1 to add the derived identification;

[0039] For each derived requirement, compile the "derivation reason" attribute to explain the derivation basis or design considerations of the derived requirement;

[0040] For each derivative requirement, compile the "Derivative Impact Analysis" attribute to describe the implementation effect of the derivative requirement from the perspective of system functions;

[0041] For each requirement, compile the "Verification Method" attribute to describe the verification method of the requirement, generally including review, analysis, and testing, which is used to illustrate the verification method to be adopted for this requirement and indicate the verifiability of the requirement;

[0042] For each requirement, compile the "Verification Considerations" attribute to describe the suggestions of the requirement developers on the goals or concerns of the verification of this requirement, which is used to assist the verification personnel in understanding the requirements and designing test cases more accurately;

[0043] Step 4: Derivative Requirement Feedback Evaluation.

[0044] Based on the derivative requirements developed in Step 1 and the "Derivative Reasons" and "Derivative Impact Analysis" attributes compiled in Step 3, organize and form a derivative requirement feedback evaluation list, and transfer it to the system and system security processes;

[0045] System personnel and system security personnel need to evaluate the rationality of each derivative requirement item by item and write evaluation descriptions and conclusions;

[0046] After the evaluation, system personnel and system security personnel need to feedback the evaluation results to the software requirements process;

[0047] Software requirements personnel complete the iterative development of software requirements according to the evaluation opinions and re-execute the derivative requirement feedback evaluation activities until all derivative requirements are evaluated and passed;

[0048] Step 5: Requirement Review. Based on the various elements of software requirements formed in Steps 1 to 4, including requirement text, traceability, requirement attributes, and derivative evaluation conclusions, establish a software requirement baseline; conduct a peer review of software requirements for this requirement baseline; the peer review checklist is set with reference to Table A-3 of DO-178C, and the peer review of software requirements needs to form a review description and review conclusion for each requirement and each inspection item.

Claims

1. A development method for the control software evidence chain of a numerical control system meeting civil aircraft requirements, characterized in that It includes the following steps: (1) Develop and identify software requirements; (2) Establish two-way traceability of requirements; (3) Develop the requirement attributes of the software; (4) Derive feedback evaluation of requirements; (5) Conduct requirement reviews to form review descriptions and review conclusions.

2. The method for developing the evidence chain of the numerical control system control software for civil aircraft requirements according to claim 1, wherein The step (1) includes developing software requirements based on the system requirements assigned to the software and the results of system security impact analysis, and defining software-derived requirements; identifying the software-derived requirements and the software requirements decomposed from the system requirements, and recording the identification as the whether requirement attribute.

3. The method for developing the evidence chain of the numerical control system control software for civil aircraft requirements according to claim 2, characterized in that, The software requirements decomposed from the system requirements are identified as R, and the software-derived requirements are identified as R-derived, and are recorded in the whether requirement attribute.

4. The method for developing an evidence chain of a CNC system control software for civil aircraft requirements according to claim 1, characterized in that The step (2) includes establishing corresponding traceability according to the decomposition relationship between the software requirements and the system requirements. When establishing two-way traceability between the software requirements and the system requirements, if it is found that there are system requirements not taken over by the software requirements, or the system requirements are not fully covered by the software requirements, then return to step (1) to supplement the relevant requirements; if it is found that the software-derived requirements are mis-identified or not identified, then return to step (1) to iterate the identification of the derived requirements.

5. The method for developing the evidence chain of the numerical control system control software for civil aircraft requirements according to claim 1, wherein The requirement attributes in the step (3) include security requirements, which are used to identify whether the requirement has a security impact; requirement decomposition description, which is used to explain the basis for decomposing the software requirements; derivation reason, which is used to explain the derivation basis or design consideration of the derived requirements; derivation impact analysis, which describes the implementation effect of the derived requirements from the perspective of system functions, and is used to assist system personnel and security personnel to quickly understand the derived requirements; derivation impact analysis, which describes the implementation effect of the derived requirements from the perspective of system functions, and is used to assist system personnel and security personnel to quickly understand the derived requirements; verification method, which is used to explain the verification method to be adopted for the requirement, indicating the verifiability of the requirement; verification consideration, which describes the suggestions of the requirement developers on the verification goals or concerns of the requirement, and is used to assist the verification personnel to understand the requirements and design test cases more accurately.

6. The method for developing an evidence chain of a CNC system control software for civil aircraft requirements according to claim 1, wherein The step (3) includes: (3.1) Identify software security requirements and identify them in the security requirement attributes; (3.2) Compile requirement decomposition description attributes according to the formed traceability matrix, and elaborate on the corresponding relationship between the requirements of the software requirements and the system requirements; if it is found during the compilation of this attribute that the requirements of the software requirements exceed the system requirements and are not identified as derived requirements, then it is necessary to return to (3.1) to supplement the derived identification.

7. The method for developing an evidence chain of a numerical control system control software for civil aircraft requirements according to claim 1, wherein In the step (3.1), the software security requirements include: the software requirements decomposed from the system security requirements need to be identified as software security requirements; the requirements with security impacts in the software-derived requirements need to be identified as software security requirements.

8. The method for developing an evidence chain of a numerical control system control software for civil aircraft requirements according to claim 1, wherein The step (4) includes sorting out and forming a derived requirement feedback evaluation list according to the derived requirements developed in step (1) and the derived reason and derived impact analysis attributes compiled in step (3), and transmitting it to the system and system security processes.

9. The method for developing the evidence chain of the CNC system control software for civil aircraft requirements according to claim 8, characterized in that, The step (4) includes: System personnel and system security personnel evaluate the rationality of the derived requirements item by item and write evaluation descriptions and conclusions; System personnel and system security personnel feedback the evaluation results to the software requirement process after the evaluation is completed; The software requirements personnel complete the iterative development of software requirements according to the evaluation opinions, and re-execute the derived requirements feedback evaluation activity until all derived requirements are evaluated and passed.

10. The method for developing an evidence chain of a numerical control system control software for civil aircraft requirements according to claim 1, characterized in that The said step (5) includes establishing a software requirements baseline based on the various elements of software requirements formed in steps (1) to (4), including requirement text, traceability, requirement attributes, and derived evaluation conclusions; conducting a peer review of software requirements for this requirements baseline; the peer review checklist is set with reference to Table A-3 of DO-178C, and the peer review of software requirements forms a review description and review conclusion item by item for each requirement and each inspection item.

Images