Research on the Requirement Validation Process of an eVTOL Aircraft †
Zero Gravity Aircraft Industry (Hefei) Co., Ltd., Nanjing 211167, China
*
Author to whom correspondence should be addressed.
†
Presented at the 2nd International Conference on Green Aviation (ICGA 2024), Chengdu, China, 6–8 November 2024.
Eng. Proc. 2024, 80(1), 16; https://doi.org/10.3390/engproc2024080016
Published: 7 January 2025
(This article belongs to the Proceedings of 2nd International Conference on Green Aviation (ICGA 2024))
Abstract
According to the SAEARP4754B standard, the positive development of electric vertical takeoff and landing (eVTOL) aircraft must carry out requirement management in order to ensure the traceability of requirements. The requirement validation process plays a key role in the requirement traceability process, and this paper is mainly about the research on the requirement validation process. The steps of optimizing the requirement validation process are to formulate validation plans, define the initial validation matrix template, select the validation approach, implement requirement validation, and notify the relevant parties of the problems found in validation. The implementation of the optimized requirement validation process avoids human error to some extent.
1. Introduction
Electric vertical-take-off and landing (eVTOL) aircraft, unlike large conventional airplanes, are powered by batteries. The battery system, flight control system, and electric motor system are cross-linked and coupled to form the complex system of the aircraft [1,2]. It is difficult to avoid human error in the development of complex systems, so it is necessary to carry out requirement management. In the process of requirement management, the most important factor to avoid errors in the development of complex systems is to design the qualification process of requirement management reasonably.
2. Requirement Validation in 4754B
The results of the assignment of the development assurance levels in the table of the Process objectives, outputs, and System Control category are determined by Aircraft Functional Hazard Assessment (AFHA) and System Functional Hazard Assessment (SFHA) [3]. Firstly, an FHA analysis is carried out, and the results of the FHA analysis are used to develop and allocate the guarantee levels of various requirements (requirement sources) of related functions, and the allocation results are the derived security requirements of each level. According to the Function Development Assurance Level allocation results, we determine the validation-supporting evidence to be submitted. The Process objectives, outputs, and System Control category is shown in the following table.
According to the different development assurance levels of requirement-related functions, the corresponding relationship table between the development assurance levels of the requirement-related functions and process objectives and outputs is queried to determine the approach and materials to be adopted for requirement validation, and the specific content is shown in Table 1 below.
Function Development Assurance Levels A, B, and C all require validation plans, validation matrices, and validation summaries. The requirement validation matrix template defined in this process includes a validation summary. Preliminary Aircraft Safety Assessment (PASA) or Preliminary System Safety Assessment (PSSA) should be provided as validation support evidence for the derived requirements. Functional Development Assurance Level (FDAL) is one of the validation approaches that must be selected for both A- and B-level requirements, including analysis, modeling, or testing, and engineering review. The table of the Process objectives, outputs, and System Control category is the work that needs to be carried out in the requirement validation specified in Appendix A of ARP4754B. The table of Requirement Validation Approach and Data Sheet corresponds to Table 2.
3. Requirement Validation Process
The sequence of requirement validation process: Formulation of validation plan→Determination of Preliminary validation matrix template→Selection of validation approach→implementation of requirement validation→notify the relevant parties of the problems found in the validation.
3.1. Formulation of Validation Plan
The person in charge at the corresponding level shall formulate the corresponding validation plan with the assistance of relevant personnel (requirement validation personnel). The contents of the validation plan include the following:
- Identification of the roles and responsibilities associated with the validation;
- Application of the validation method;
- A schedule of the key validation activities;
- The approach of managing assumptions at the different design levels and phases of development;
- How to maintain and manage validation status when changes are made to requirements;
- The means to be used to provide the independence of the requirement definition from the validation activities. Aspects of the validation process that may also serve as part of verification should be coordinated with the verification plan.
3.2. Determination of Preliminary Validation Matrix Template
The security engineer defines the initial validation matrix template, which is updated iteratively during the actual requirement validation process, and finally determines the appropriate requirement validation template. The template of the requirement validation matrix is shown in Table 3 below.
3.3. Selection of Validation Approach
Requirement validation approaches include the following: analysis, simulation or testing, similarity, and engineering review. The requirements for the intended function should be identified by assessing whether the requirements for the intended function can pass the target pass/fail criteria.
Requirement validation personnel at all levels select the appropriate validation approaches for requirement validation, and the validation approaches are written in the requirement validation matrix. Validation may be supported by several approaches, including traceability, analysis, modeling, testing, similarity, and engineering judgment. The validation method can be found in the literature [4,5].
3.4. Implementation of Requirement Validation
(1) Capture requirement validation evidence
Validation evidence shall be in the corresponding form of validation method, including but not limited to: expert review (review meeting minutes); analysis (analysis report); modeling (model); test (test report); and similarity (similarity analysis report). Related reports generated during the validation process must be incorporated into configuration management. The requirement validation executor records the requirement validation results in the requirement validation matrix. The name, document code, and version information of the referenced documents must be clearly indicated when the supporting evidence of the validation is cited.
(2) Completion of Requirement Validation Matrix
According to the development assurance level of the requirement-related functions, query the requirement validation method and data sheet, select the corresponding requirement validation method, confirm the requirements submit the corresponding validation supporting evidence, and fill in the validation result. Finally, check the completeness and correctness of the requirements, and fill in the review results; review the validation matrix and fill in the requirement review validation conclusion.
(3) Correctness and Completeness Checks
We can use the correctness checklist to check the correctness of the requirements. If the check fails to generate a problem report, the problem report is submitted to the requirement compiler for corresponding modification. Problem reporting management is also a part of configuration management and adopts a configuration management process.
Requirements have subordinate modules, such as function module requirements, performance module requirements, and security module requirements. Different module requirements, that is, different categories of requirements, are assigned to a certain person for correctness check or completeness check. The results for correctness and completeness in the requirement validation matrix refer to the requirement correctness checklist and completeness checklist.
We can use the completeness checklist to check the completeness of the requirements. If the check fails to generate a problem report, the problem report is submitted to the requirement compiler for corresponding modification [6].
(4) Determination of Requirement Validation Summary
It is necessary to prepare a summary document of requirement validation, which includes validation evidence (requirements containing assumptions include validation evidence of assumptions), validation methods, validation results, and corresponding improvement suggestions. After confirming the compilation of the summary document, control it according to the process of configuration management.
3.5. Notify the Relevant Parties of the Problems Found in the Validation
If a requirement fails to meet all the criteria for correctness and completeness, the requirement validation owner shall record the reasons for the requirement not meeting the criteria for correctness and completeness in detail, notify the corresponding requirement capture person and the requirement owner, and provide a problem report. Among them, the problem report also contains corresponding suggestions for improvement.
4. Conclusions
In the development process of eVTOL aircraft, requirement validation is a key and complex system engineering, and the correctness and completeness of requirements affect the progress and quality of aircraft development. Through the effective requirement validation process, the correctness and completeness of the early requirements of the aircraft and the stability of the requirements in the whole life cycle of the aircraft development are ensured [7,8].
Author Contributions
Conceptualization, H.Y. and Y.L.; methodology, H.Y.; validation, H.Y., Y.L. and J.H.; formal analysis, H.Y.; investigation, H.Y.; resources, H.Y.; data curation, H.Y.; writing—original draft preparation, H.Y.; writing—review and editing, Y.L. and J.H.; visualization, J.H. All authors have read and agreed to the published version of the manuscript.
Funding
This research received no external funding.
Institutional Review Board Statement
Not applicable.
Informed Consent Statement
Not applicable.
Data Availability Statement
Data are contained within the article.
Conflicts of Interest
Authors Haiyun Yang Yiheng Li and Jing Hu were employed by the company Zero Gravity Aircraft Industry (Hefei) Co., Ltd. The authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.
References
- Liu, J.J.; Tan, Y.S. Safety evaluation of the power system of electric vertical take-off and landing vehicles with different configurations. J. Harbin Eng. Univ. 2024, 45, 339–348. (In Chinese) [Google Scholar]
- Liu, J.J.; Tan, Y.S. Architecture design of flight control system for electric vertical takeoff and landing aircraft based on safety analysis. J. Chongqing Univ. 2024, 47, 67–75. (In Chinese) [Google Scholar]
- SAE. ARP4754 Guidelines for Development of Civil Aircraft and Systems; SAE: Warrendale, PA, USA, 2023. [Google Scholar]
- Lu, Z.N. Research and Practice of DAL-A Requirement Validation in SAE 4754A. In Proceedings of the China Aeronautical Science and Technology Conference (CASTC 2023), Beijing, China, 8–10 December 2023; Beihang University Press: Beijing, China, 2023; Volume 6. (In Chinese). [Google Scholar]
- Tan, Z.Z. Requirements Analysis and Validation of Automatic Flight Control Systems for Civil Aircraft. China Acad. J. Electron. Publ. House 2016, 26, 254–255. (In Chinese) [Google Scholar]
- Guo, B.Z.; Wang, M.Q.; Ruan, H.Z. Safety Design and Vertification in Civil Aircraft; Aviation Industry Press: Beijing, China, 2015. (In Chinese) [Google Scholar]
- Li, Y.Y.; Zhao, H.Y.; Wei, P. Research on the Requirement Capture and Validation Strategy of the Automatic Flight Control System of Civil Aircraft. Sci. Technol. Inf. 2023, 21, 245–249. (In Chinese) [Google Scholar]
- Tian, B. Research on Requirement Management Process for Civil Aircraft Complicated System. Civ. Aircr. Des. Res. 2016, 89–92. (In Chinese) [Google Scholar]
Table 1.
Process objectives, outputs, and System Control category.
| Objective | Objective Applicability and Independence by FDAL | Output | Comments | |||||
|---|---|---|---|---|---|---|---|---|
| Objective No. | Objective Description | A | B | C | D | E | ||
| 1 | Aircraft and system requirements are complete and correct. | R* | R* | R | R | N | Validation results | Includes coordination of interfaces between systems and between items. System requirements include those allocated to items. Validation affords the opportunity to identify and address unintended behaviors. |
| 2 | Assumptions are managed. | R* | R* | R | R | N | Validation results | |
| 3 | The functional and safety impacts of derived requirements are acceptable at relevant higher levels. | R* | R* | R | R | N | Validation results | |
| 4 | Validation substantiation is provided. | R | R | R | A | N | Validation Summary (including Validation Matrix) | |
Note: R*—recommended for certification with process independence; R—recommended for certification; A—as negotiated for certification; N—not required for certification. * the independence of requirement validation is satisfied when the activities are not performed by the person who wrote the requirements.
Table 2.
Requirement Validation Approach and Data Sheet.
| Approach and Data Sheet | DAL A, B | DAL C | DAL D | DAL E |
|---|---|---|---|---|
| Validation plans | R | R | A | N |
| Validation matrices | R | R | A | N |
| Validation summaries | R | R | A | N |
| The security impact and functionality of the derived requirements are compatible with the previous level (PSSA/PASA analysis result) | R | R | A | N |
| Analysis, Modeling, or Testing | R | A | A | N |
| Engineering Review (Personnel, Roles, and Review Records) | R | A | A | N |
| Similarity (Service Experience) | A | A | A | N |
Note: R—recommended for certification; A—as negotiated for certification; N—not required for certification.
Table 3.
Requirement validation matrix.
| No. | Assumption | Requirement Sources/Previous Level Requirements/Requirement Evidence (Derived Requirements) | Requirements Content | Dal | Validation Approach | Validation Support Evidence | Validation Personnel | Validation Result | Completeness Checks | Correctness Checks | Review Personnel | Requirement Review Validation Result | ||
| Review personnel | Result | Review personnel | Result | |||||||||||
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content. |
© 2025 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).
Share and Cite
MDPI and ACS Style
Yang, H.; Li, Y.; Hu, J. Research on the Requirement Validation Process of an eVTOL Aircraft. Eng. Proc. 2024, 80, 16. https://doi.org/10.3390/engproc2024080016
AMA Style
Yang H, Li Y, Hu J. Research on the Requirement Validation Process of an eVTOL Aircraft. Engineering Proceedings. 2024; 80(1):16. https://doi.org/10.3390/engproc2024080016
Chicago/Turabian StyleYang, Haiyun, Yiheng Li, and Jing Hu. 2024. "Research on the Requirement Validation Process of an eVTOL Aircraft" Engineering Proceedings 80, no. 1: 16. https://doi.org/10.3390/engproc2024080016
APA StyleYang, H., Li, Y., & Hu, J. (2024). Research on the Requirement Validation Process of an eVTOL Aircraft. Engineering Proceedings, 80(1), 16. https://doi.org/10.3390/engproc2024080016
