Complex Systems Design & Management: Proceedings of the 14th International Conference on Complex Systems Design & Management CSD&M 2023 (Lecture Notes in Electrical Engineering, 1085) 9819965101, 9789819965106

Citation preview

Lecture Notes in Electrical Engineering 1085

Daniel Krob · Lefei Li · Xinguo Zhang · Junchen Yao · Mengyu Guo Editors

Complex Systems Design & Management Proceedings of the 14th International Conference on Complex Systems Design & Management CSD&M 2023

Lecture Notes in Electrical Engineering

1085

Series Editors Leopoldo Angrisani, Department of Electrical and Information Technologies Engineering, University of Napoli Federico II, Napoli, Italy Marco Arteaga, Departament de Control y Robótica, Universidad Nacional Autónoma de México, Coyoacán, Mexico Samarjit Chakraborty, Fakultät für Elektrotechnik und Informationstechnik, TU München, München, Germany Jiming Chen, Zhejiang University, Hangzhou, Zhejiang, China Shanben Chen, School of Materials Science and Engineering, Shanghai Jiao Tong University, Shanghai, China Tan Kay Chen, Department of Electrical and Computer Engineering, National University of Singapore, Singapore, Singapore Rüdiger Dillmann, University of Karlsruhe (TH) IAIM, Karlsruhe, Baden-Württemberg, Germany Haibin Duan, Beijing University of Aeronautics and Astronautics, Beijing, China Gianluigi Ferrari, Dipartimento di Ingegneria dell’Informazione, Sede Scientifica Università degli Studi di Parma, Parma, Italy Manuel Ferre, Centre for Automation and Robotics CAR (UPM-CSIC), Universidad Politécnica de Madrid, Madrid, Spain Faryar Jabbari, Department of Mechanical and Aerospace Engineering, University of California, Irvine, CA, USA Limin Jia, State Key Laboratory of Rail Traffic Control and Safety, Beijing Jiaotong University, Beijing, China Janusz Kacprzyk, Intelligent Systems Laboratory, Systems Research Institute, Polish Academy of Sciences, Warsaw, Poland Alaa Khamis, Department of Mechatronics Engineering, German University in Egypt El Tagamoa El Khames, New Cairo City, Egypt Torsten Kroeger, Intrinsic Innovation, Mountain View, CA, USA Yong Li, College of Electrical and Information Engineering, Hunan University, Changsha, Hunan, China Qilian Liang, Department of Electrical Engineering, University of Texas at Arlington, Arlington, TX, USA Ferran Martín, Departament d’Enginyeria Electrònica, Universitat Autònoma de Barcelona, Bellaterra, Barcelona, Spain Tan Cher Ming, College of Engineering, Nanyang Technological University, Singapore, Singapore Wolfgang Minker, Institute of Information Technology, University of Ulm, Ulm, Germany Pradeep Misra, Department of Electrical Engineering, Wright State University, Dayton, OH, USA Subhas Mukhopadhyay, School of Engineering, Macquarie University, NSW, Australia Cun-Zheng Ning, Department of Electrical Engineering, Arizona State University, Tempe, AZ, USA Toyoaki Nishida, Department of Intelligence Science and Technology, Kyoto University, Kyoto, Japan Luca Oneto, Department of Informatics, Bioengineering, Robotics and Systems Engineering, University of Genova, Genova, Genova, Italy Bijaya Ketan Panigrahi, Department of Electrical Engineering, Indian Institute of Technology Delhi, New Delhi, Delhi, India Federica Pascucci, Department di Ingegneria, Università degli Studi Roma Tre, Roma, Italy Yong Qin, State Key Laboratory of Rail Traffic Control and Safety, Beijing Jiaotong University, Beijing, China Gan Woon Seng, School of Electrical and Electronic Engineering, Nanyang Technological University, Singapore, Singapore Joachim Speidel, Institute of Telecommunications, University of Stuttgart, Stuttgart, Germany Germano Veiga, FEUP Campus, INESC Porto, Porto, Portugal Haitao Wu, Academy of Opto-electronics, Chinese Academy of Sciences, Haidian District Beijing, China Walter Zamboni, Department of Computer Engineering, Electrical Engineering and Applied Mathematics, DIEM—Università degli studi di Salerno, Fisciano, Salerno, Italy Junjie James Zhang, Charlotte, NC, USA Kay Chen Tan, Department of Computing, Hong Kong Polytechnic University, Kowloon Tong, Hong Kong

The book series Lecture Notes in Electrical Engineering (LNEE) publishes the latest developments in Electrical Engineering—quickly, informally and in high quality. While original research reported in proceedings and monographs has traditionally formed the core of LNEE, we also encourage authors to submit books devoted to supporting student education and professional training in the various fields and applications areas of electrical engineering. The series cover classical and emerging topics concerning: • • • • • • • • • • • •

Communication Engineering, Information Theory and Networks Electronics Engineering and Microelectronics Signal, Image and Speech Processing Wireless and Mobile Communication Circuits and Systems Energy Systems, Power Electronics and Electrical Machines Electro-optical Engineering Instrumentation Engineering Avionics Engineering Control Systems Internet-of-Things and Cybersecurity Biomedical Devices, MEMS and NEMS

For general information about this book series, comments or suggestions, please contact [email protected]. To submit a proposal or request further information, please contact the Publishing Editor in your country: China Jasmine Dou, Editor ([email protected]) India, Japan, Rest of Asia Swati Meherishi, Editorial Director ([email protected]) Southeast Asia, Australia, New Zealand Ramesh Nath Premnath, Editor ([email protected]) USA, Canada Michael Luby, Senior Editor ([email protected]) All other Countries Leontina Di Cecco, Senior Editor ([email protected]) ** This series is indexed by EI Compendex and Scopus databases. **

Daniel Krob · Lefei Li · Xinguo Zhang · Junchen Yao · Mengyu Guo Editors

Complex Systems Design & Management Proceedings of the 14th International Conference on Complex Systems Design & Management CSD&M 2023

Editors Daniel Krob CESAMES Paris, France Xinguo Zhang Tsinghua University Beijing, China Mengyu Guo Department of Industrial Engineering Tsinghua University Beijing, China

Lefei Li Department of Industrial Engineering Tsinghua University Beijing, China Junchen Yao Chinese Society of Aeronautics and Astronautics Beijing, China

ISSN 1876-1100 ISSN 1876-1119 (electronic) Lecture Notes in Electrical Engineering ISBN 978-981-99-6510-6 ISBN 978-981-99-6511-3 (eBook) https://doi.org/10.1007/978-981-99-6511-3 © The Editor(s) (if applicable) and The Author(s), under exclusive license to Springer Nature Singapore Pte Ltd. 2023 This work is subject to copyright. All rights are solely and exclusively licensed by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. The publisher, the authors, and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors give a warranty, expressed or implied, with respect to the material contained herein or for any errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in published maps and institutional affiliations. This Springer imprint is published by the registered company Springer Nature Singapore Pte Ltd. The registered company address is: 152 Beach Road, #21-01/04 Gateway East, Singapore 189721, Singapore Paper in this product is recyclable.

Preface

Introduction This volume contains the proceedings of the 14th International Conference on Complex Systems Design & Management (CSD&M 2023) which are two international series of conferences on systems architecting, modeling, and engineering that merged this year (see the conference website http://2023.csdmconference.com/ for more details). Organized by the Chinese Society of Aeronautics and Astronautics (CSAA) and by the Center of Excellence on Systems Architecture, Management, Economy & Strategy (CESAMES) with the support of its Chinese branch, CESAMES China, the 14th CSDM edition was held in Beijing for two days. The conference also benefited from the sponsorship and technical and financial support of many organizations such as AVIC Digital, AVIC China Aeronautical Radio Electronics Research Institute, AVIC Xian Flight Automatic Control Research Institute, China Instrument & Control Society, Chinese Institute of Electronics, Chinese Society of Astronautics, Chinese Society of Naval Architects and Marine Engineers, Dassault Systèmes, INCOSE, INCOSE Asia-Oceania Sector, Pure Systems, PGM Technology, and Tsinghua University. Our sincere thanks therefore to all of them. Many other academic, governmental, and industrial organizations were involved in the CSD&M 2023 program and organizing committees. We would like to sincerely thank all their members who helped a lot through their participation and contribution during the conference preparation.

Why a CSD&M Conference? Mastering complex systems requires an integrated understanding of industrial practices as well as sophisticated theoretical techniques and tools. This explains the creation of an annual go-between forum—which did not exist before—alternating between Europe and Asia and jointly dedicated to academic researchers and governmental and industrial actors working on complex industrial systems architecting, modeling, and engineering. Facilitating their meeting was actually for us a sine qua non condition in order to nurture and develop in Europe and Asia the science of systems which is currently emerging and developing worldwide. The purpose of the “Complex Systems Design & Management” (CSD&M) conference is exactly to be such a forum. Its aim is to progressively be the European and Asian academic-industrial conference of reference in the field of complex industrial systems architecting, modeling, and engineering, which is a quite ambitious objective. The last thirteen CSD&M conferences—which were all held from 2010 to 2020 in Paris (France), then by 2021 in Beijing (China) and by 2022 in Paris (France)—and three CSD&M Asia conferences—which were all held from 2014 to 2018 in Singapore—were the first steps in this direction. Last year, after many difficulties due to the

vi

Preface

COVID-19 crisis, participants were again 300 to attend our two-day CSD&M 2022 conference in Paris, which proves that the interest in systems architecting, modeling, and engineering does not fade. In 2021, a key point was the merge of our two previously independent European and Asia-Pacific streams, resulting in a unique CSD&M series which is alternating between Europe and Asia from now on.

Our Core Academic—Industrial Dimension To make the CSD&M conference a convergence point between the academic, governmental, and industrial communities working in complex industrial systems, we based our organization on a principle of parity between academics and industrialists (see the conference organization sections in the next pages). This principle was implemented as follows: • program committee consisted of 50 % academics and 50 % industrialists, and • invited speakers came in a balanced way from numerous professional environments. The set of activities of the conference followed the same principle. They indeed consist of a mixture of research seminars and industrial experience sharing, academic articles and industrial presentations, software tools and training offering presentations, etc. The conference topics cover the most recent trends in the emerging field of complex systems sciences and practices from both an academic and industrial perspective, including the main industrial domains (aeronautics and aerospace, defense and security, energy and environment, high tech and electronics, software and communication, transportation), scientific and technical topics (systems fundamentals, systems architecting, modeling and engineering, systems metrics and quality, systems safety, systems integration, systems verification and validation, model-based systems engineering and simulation tools) and types of systems (transportation systems, embedded systems, energy production systems, communication systems, software and information systems, systems of systems).

CESAM Community The CSD&M series of conferences are organized under the guidance of CESAM Community (see http://cesam.community/en), managed by the Center of Excellence on Systems Architecture, Management, Economy & Strategy (CESAMES; see http://cesames. net/ and http://cesames.cn/). CESAM Community aims in organizing the sharing of good practices in systems architecting and model-based systems engineering (MBSE) and certifying the level of knowledge and proficiency in this field through the CESAM certification. The CESAM systems architecting and model-based systems engineering (MBSE) certification is especially currently the most disseminated professional certification in the world in this domain through more than 3,000 real complex system development projects on which it was deployed and around 10,000 engineers who were trained on the CESAM framework at international level.

Preface

vii

The CSD&M 2023 Edition The CSD&M 2023 edition received 56 submitted papers, out of which the program committee selected 34 regular papers to be published as full papers in the conference proceedings. The program committee also selected 30 papers for a collective presentation during the poster workshop of the conference. Each submission was assigned to at least two program committee members, who carefully reviewed it, in many cases with the help of external referees. These reviews were discussed by the program committee during an online meeting that took place by July 9, 2023, and was managed through the EasyChair conference system. We also chose several outstanding speakers with great scientific and industrial expertise who gave a series of invited talks covering the complete spectrum of the conference during the two days of CSD&M 2023. The conference was organized this year around a common topic: “New Trends in Complex Systems Engineering”. Each day proposed various invited keynote speakers’ presentations on this topic and a “à la carte” program consisting in accepted paper presentations managed in different sessions. Furthermore, we had “poster workshops”, to encourage presentation and discussion on interesting, but “not-yet-polished”, ideas. Finally, CSD&M 2023 also offered booths presenting the last state-of-the-art engineering and technological tools to the conference participants. July 2023

Daniel Krob Xinguo Zhang Lefei Li Junchen Yao Mengyu Guo

Conference Organization

Conference Chairs General Co-chairs Krob Daniel

Zhang Xinguo

Institute Professor at Ecole Polytechnique, President of CESAMES, INCOSE Fellow, France Distinguished Professor, Director of the Complex Systems Engineering Research Center, Tsinghua University, INCOSE ESEP, President of INCOSE Beijing Chapter, People’s Republic of China

Organizing Committee Chair Yao Junchen

Secretary General, CSAA, People’s Republic of China

Program Committee Co-chairs Li Lefei (academic Co-chair)

Zhang Wenfeng (Industrial Co-chair)

Associate Professor, Secretary of the Department of Industrial Engineering, Tsinghua University, People’s Republic of China Chief Scientist of National Key Research and Development Program and Chairman of MBSE Committee at MBSE Laboratory of Aerospace System Engineering Institute

Program Committee The program committee consists of 18 members (12 academics and six industrialists) of high international visibility. Their expertise spectrum covers all of the conference topics.

x

Conference Organization

Academic Members Co-chair Li Lefei (Academic Co-chair)

Associate Professor, Secretary of the Department of Industrial Engineering, Tsinghua University, People’s Republic of China

Members Chang Chuangye Prun Daniel

Bonjour Eric Guo Mengyu Coatanea Eric Boy Guy-André

Kennedy Grace

Xu Yuan Wang Chen Xie Xiaolei Lv Yisheng

Research Associate Professor, Beihang University, People’s Republic of China Associate Professor, Ecole Nationale de l’Aviation Civile—French National School of Civil Aviation, France Full Professor, University of Lorraine, France Assistant Professor, Tsinghua University, People’s Republic of China Professor, Tampere University, Finland INCOSE Fellow, FlexTech Chair Professor, Paris Saclay University—CentraleSupélec and ESTIA, France CPEng, CSEP, Lecturer in OHS (Human Factors and Ergonomics), Research Fellow in Systems Engineering, University of Wollongong, Australia Professor, Beijing Institute of Technology, People’s Republic of China Associate Professor, Tsinghua University, People’s Republic of China Associate professor, Tsinghua University, People’s Republic of China Researcher, Chinese Academy of Sciences, People’s Republic of China

Conference Organization

xi

Industrial Members Co-Chair Zhang Wenfeng (Industrial Co-chair)

Chief Scientist of National Key Research and Development Program and Chairman of MBSE Committee at MBSE Laboratory of Aerospace System Engineering Institute, People’s Republic of China

Members D’souza Adriana

Delicado Bernardo Wen Yuejie Zhang Chi

Yip Yew Seng

Configuration Management CoC—Systems, AIRBUS, CSEP, EMEA Co-Chair of the INCOSE Configuration Management Working Group, UK PhD/INCOSE ESEP, Systems Engineering Senior Expert at INDRA, Spain Researcher, China Academy of Space Technology, People’s Republic of China Expert at Beijing Civil Aircraft Technology Research Institute (BATRI) of COMAC, People’s Republic of China General Manager/Vice President Business Development at ARETE and Management Committee Member at INCOSE, Singapore

Organizing Committee The organizing committee consists of 12 academic and industrial members of high international visibility. The organizing committee is in charge of defining the program of the conference and of identifying the keynote speakers. The organizing committee also has to ensure the good functioning and organization of the event (communication, sponsoring,…). Chair Yao Junchen

Secretary General, CSAA, People’s Republic of China

xii

Conference Organization

Members Cao Xueqin Cao Zheng Christophe Tilmont Han Yi Lu Daming Pearl Jwo Qu Yanbing Wang Junli

Wang Yiran

Zhang John Zhang Xue

Vice Secretary General, Chinese Institute of Electronics (CIE), People’s Republic of China Director, China Instrument and Control Society (CIS), People’s Republic of China VP Marketing and Communication, CESAMES, France Secretary General, China Electrotechnical Society (CES), People’s Republic of China Vice President, Chinese Mechanical Engineering Society (CMES), People’s Republic of China Head of Int’l Dvpt Focus Asia, CESAMES, France Vice Secretary General, China Ordnance Society (COS), People’s Republic of China Secretary General, Chinese Society of Naval Architects and Marine Engineers (CSNAME), People’s Republic of China VP and Secretary General, Chinese Society of Astronautics (CSA), People’s Republic of China National Distinguished Expert, Industry MBSE Expert, People’s Republic of China Director, Department of International Cooperation, Chinese Society of Aeronautics and Astronautics (CSAA), People’s Republic of China

Invited Speakers Plenary Sessions Boy Guy-André

Rauzy Antoine

INCOSE Fellow, FlexTech Chair Professor, Paris Saclay University—CentraleSupélec and ESTIA, France Professor, Norwegian University of Science and Technology, Norway

Conference Organization

Zhang Wenfeng

Krob Daniel

Zhang Xinguo

xiii

Chief Scientist of National Key Research and Development Program and Chairman of MBSE Committee at MBSE Laboratory of Aerospace System Engineering Institute, People’s Republic of China Institute Professor at Ecole Polytechnique, President of CESAMES, INCOSE Fellow, France Distinguished Professor, Director of Complex Systems Engineering Research Center, Tsinghua University, China INCOSE ESEP, President of INCOSE Beijing Chapter, People’s Republic of China

NB. at the time of publication, we are still waiting for the confirmation of some invited speakers; you will find all of them on the conference website. The organizers of the conference are grateful to the following partners without whom the CSD&M 2023 event would not exist: • Founding partner – CESAM Community managed by CESAMES (Center of Excellence on Systems Architecture, Management, Economy and Strategy) • Industrial and institutional partners – The AVIC China Aeronautical Radio Electronics Research Institute - 航空工业 无线电电子研究所 – The AVIC Xian Flight Automatic Control Research Institute - 航空工业西安飞 行自动控制研究所 – Beihang university - 北京航空航天大学 – The China Instrument & Control Society - 中国仪器仪表学会 – The China State Shipbuilding Corporation Limited - 中国船舶集团有限公司, – The Chinese Institute of Electronics - 中国电子学会 – The Chinese Society of Astronautics - 中国宇航学会 – The Chinese Society of Naval Architects and Marine Engineers - 中国造船工程 学会 – The French Group Dassault Systèmes - 达索集团 – The German company Pure Systems – 德国Pure Systems公司 – The International Council on Systems Engineering (INCOSE) - 国际系统工程 协会 – The International Council on Systems Engineering (INCOSE) Asia-Oceania Sector - 国际系统工程协会亚太区 – The Chinese company PGM Technology - 中国仆勾山科技有限公司 – Tsinghua University, Department of Industrial Engineering - 清华大学工业工 程系 At the time of publication, we are still waiting for the confirmation of other partners; you will find all of them on the conference websites.

Acknowledgements

We would like to thank all the members of the program and organizing committees for their time, efforts, and contributions to make CSD&M 2023 a top-quality conference. Special thanks also go to the CESAM Community, CESAMES, and CSAA teams who permanently and efficiently managed the administration, communication, and logistics of the CSD&M 2023 conference (for more details, see http://cesam.community/en, http:// cesames.net/, http://cesames.cn/ and http://www.csaa.org.cn/).

Contents

An Architectural Design and Architectural Transformation Method Based on the Complex Real-Time Embedded Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hongxin Ji, Fuxing Tao, Hongbo Ma, Jiangtao Feng, and Lin Yang A Generalized Reuse Framework for Systems Engineering . . . . . . . . . . . . . . . . . . Gan Wang The Research on the Task Scheduling and Optimization Technology for Flight Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bei Tian, Gang Xiao, Jun Hong, and Yu Shen A Systematic Approach to Conducting FHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jian Wang A Systems Engineering Framework that Integrates Aircraft Final Assembly Design Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tao Li, Xiao Ding, Helen Lockett, Lei He, Bo Ye, and Shangqiang Li An Adaptive Assembly Process Modeling Approach for Aircraft Manufacturing: Distinguishing Between Product-Specific Constraints and Optimal Assembly Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lei He, Tao Li, Xiao Ding, and Xuehao Liu Research and Application of Decoupling Method for Fuel System Testing in the Final Assembly Stage of Aircraft Complex Systems . . . . . . . . . . . . . . . . . . . Bo Ye, Tao Li, Xiao Ding, Danyang Wang, Xin Luo, and Hongrui Xiong Study of MBSE Development Framework for Flying Cars . . . . . . . . . . . . . . . . . . . Lei Zhang, Yichen Shi, Yicheng Liang, and JinTen Huang A Unified SoS and System Architecture Modeling Framework Based on Grid-Type MBSE Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Yuqiang Guo, Zhirui Wang, Hui Zhao, Qiang Sun, and Junxian Guo

1

9

25

37

47

59

71

83

96

Building A Unified Model-Based SoSE and SE Tool-Chain Framework Economically Based on Data Exchange Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 105 Yuqiang Guo, Shiyan She, Keke Qi, Jun Zhao, and Junxian Guo

xviii

Contents

Model Compression Method Based on Knowledge Distilling and Adversarial Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Ming Du, Zhenhua Ma, and Yuan Liu Research on Hardware-in-the-Loop Simulation for Aircraft Electric Power System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Danyang Wang, Xiao Ding, Su Wang, Fengyun Tan, Tao Li, Bo Ye, and Jianjun Tang An Assumption of R&D Method Driven by Model and Data . . . . . . . . . . . . . . . . . 142 Wenming Song and Kui Li Research on the Model-Based Process and Method for Aviation Equipment Requirement Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Siyang Tan and Binqiang Chen Enterprise Modeling for Architecture-Centric Production Systems Planning . . . . 164 Mengyu Guo and Jiaheng Sun Model-Based Embedded Radar System Software Development and Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Yue Tan, Qinghua Long, and Min Wei Model-Based Design Method and Practice of Avionics System Architecture in Civil Aircraft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Xinyi Tang, Weizhen Yan, and Ge Song Applying Systems Thinking and Architectural Thinking to Improve Model-Based Systems Engineering Practice: Concepts and Methodology . . . . . . 200 Mengyu Guo, Zhe Wang, and Jiaheng Sun Top-Down Military System-of-Systems Design Using MBSE Based on UAF: A Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Naihao Liu, Jun Wang, Yuchen Zhang, Delin Li, and Meina Ju PRODEC-Based Task Analysis for the Design of Semi-Automated Trains . . . . . 220 Yang Sun, Guy André Boy, Marc Sango, and Anne Barros Risk Assessment Method of Aircraft Engine Product Supply Chain Based on AHP Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Chi Shao and Jian-hua Yu Design of Ground Integrated Testing Equipment Based on MBSE . . . . . . . . . . . . 245 Delong Cui, Xuan Yang, and Na Li

Contents

xix

Model Based Analysis and Verification Method for Helicopter System Performance Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Ji Xin, Zhizhong Han, and Lixia Chen A SysML-Based Architecture Framework for Helicopter . . . . . . . . . . . . . . . . . . . . 272 Le Wang, Guojun Chen, Guoding Chen, Yun Yang, Haifeng Peng, and Shengquan Feng Design and Modeling of Nuclear Power Inspection Robot Based on MBSE . . . . 289 Jia Zhang, Rongtao Wang, Tiancai Liu, Jingchi Zhang, Shasha Zhang, and Huan Zhang A Novel MBSE-Based Design Method for Search and Rescue Humanoid Robots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 Mengyue Wang, Libo Meng, Zeqi Zhang, and Yuan Xu Design Method of Task Meta-model of Avionics System Architecture Based on DM2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 Cong Chen, Jinyan Wang, Jieshi Shen, and Bingfei Li Investigation of a Model-Based Approach to a Grid Fin System Design . . . . . . . 326 Rendong Yu, Wenfeng Zhang, Liangcong Zhu, Xiong Liu, and Dongzheng Kuang Architecture Design of Model-Based Land Combat Equipment System . . . . . . . . 335 Qiang Liu, Yuan Feng, Ruihong Zhang, Long Chen, and Jing Zhou Research and Application of Model-Based Aircraft Complex Function Analysis Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 Meng Liu, QiTao Wang, Chenliang Xin, Mengmeng Yao, Yong Teng, Linlin Wen, and Xiongwei He Modeling the Impact of Interdependency Among Capabilities in System of Systems Context Using Unified Architecture Framework and Choquet Integral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 Xusheng Ren, Lefei Li, Fengfeng Huo, Qiao Li, Haoyu Qiu, Liangwei You, Hongqiao Zhu, and Jianliang Ren Research on the Concept of MAV/UAV Cooperative Combat Based on UAF . . . 375 Shuang Zhang, Xiaoguang Wang, Tong Yue, Hongrui Jiang, and Qi Liu An Effective Approach for Model-Based Radar System Architecting . . . . . . . . . . 386 Jiaheng Sun, Mengyu Guo, and Ruoxi Guan

xx

Contents

A Method for Generating Radar System Logical Architecture Models Based on Domain Ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 Chang Li, Jiajun Yuan, and Ruoxi Guan Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

An Architectural Design and Architectural Transformation Method Based on the Complex Real-Time Embedded Systems Hongxin Ji(B) , Fuxing Tao, Hongbo Ma, Jiangtao Feng, and Lin Yang Avic Information Technology CO., LTD, Beijing, China [email protected]

Abstract. The architectural design and architectural transformation method proposed in this paper is aimed at the architecture design and analysis of the complex real-time embedded systems based on the models. The architecture models, as the authoritative data source, provide data for the work of other perspectives in the whole system design process. The functional architectures of the complex realtime embedded systems are described by SysML. SysML and extended FACE Profile are used to describe the logical architecture. Describe the physical architecture through SysML and extended MARTE Profile. Based on the created functional architectures, logical architectures and physical architectures of the complex realtime embedded systems, the method is implemented through model transformation to convert SysML functional architectures, SysML and FACE Profile logical architectures, SysML and MARTE Profile physical architectures into corresponding AADL architectural models automatically, which improves the efficiency and accuracy of subsequent complex real-time embedded system architecture analysis.

1 Introduction The complex real-time embedded systems are widely used in avionics, spacecraft, automotive control and other fields. These systems have the characteristics of limited resources, real-time response, fault tolerance and dedicated hardware. Meanwhile have high requirements for real-time, safety and other performance. Due to the requirements of computational accuracy and real-time response, such systems become more and more complex. How to design and implement high quality embedded real-time systems and effectively control the development time and cost become a common problem facing academia and industry. In the traditional embedded systems development mode, from requirement analysis, system design, system implementation to system testing, there are many development links and intermediate documents, which often lead to great uncertainty and potential omission crisis in the connection between development links. Once there are obvious errors or unsatisfied requirements in the final implementation and testing stage, it cannot be repeated design across the stages, only from scratch redesign, which makes the cost of embedded system research and development greatly increased. Model Driven Development (MDD) can design and analyze the architectures of complex real-time © The Author(s), under exclusive license to Springer Nature Singapore Pte Ltd. 2023 D. Krob et al. (Eds.): CSD&M 2023, LNEE 1085, pp. 1–8, 2023. https://doi.org/10.1007/978-981-99-6511-3_1

2

H. Ji et al.

embedded systems at early stage, which helps to ensure the quality attributes of the system and effectively control the development time and cost. Quality attributes are determined by the architectures of systems. Therefore, architecture-driven design and development methods based on models have become an important research content in the field of complex real-time embedded systems [1]. Although it has gradually become a consensus to carry out model-based system architecture design and analysis based on functional (F), logical(L) and physical(P) architectures, the following defects still exist in the field of complex real-time embedded systems architecture design and analysis: the definition and characteristics of functional architecture, logical architecture and physical architecture have not been unified. At the same time, in the aspect of architectural transformation, it is almost manual transformation, and there are no complete automatic transformation methods of architectural models.

2 Research on Architectural Design Method of the Complex Real-Time Embedded Systems 2.1 Functional Architecture Design Modeling Method Based on the low-level requirements and design constraints of the complex real-time embedded systems, the functional architectures of the complex real-time embedded systems are designed. First, the functional architectures of the systems are established, including the allocation of system functional elements and the establishment of functional hierarchy. Then, the interface analysis and definition of system functional architecture elements are carried out. Secondly, the derived requirements of system functional architecture are identified. Finally, the SysML [2] functional architecture models are transformed into AADL [3] functional architecture models. Functional architecture design modeling mainly carries out functional analysis and design according to the use cases of complex real-time embedded systems to generate functional architecture. Functional architecture will abstract the concept of functions and function groups which contain multiple functions. The two concepts are represented by Block in SysML or encapsulated by Block in Profile. In order to distinguish the blocks representing function groups and functions from the blocks representing the system, they are organized by separate packages. Block Definition Diagram (BDD) is mainly used to describe function groups and the decomposition structure of functions. The interactive data flows between functions in function groups are described by Internal Block Diagram (IBD), and function flow is described by Activity Diagram. Function interaction is described by Sequence Diagram, and dynamic behavior models of function elements are described by State Machine Diagram. Port representing functions Block represents information flow port of functions, and connection is used to represent information flow connection relationship between functions. 2.2 Logical Architecture Design Modeling Method Based on the functional architectures, the logical architectures are designed. Firstly, the logical composition is defined, including establishing the logical sets, defining the

An Architectural Design and Architectural Transformation Method

3

logical entities, determining the mapping relationship between the logical entities and the functional elements, and assigning the performance indexes. Then the interface analysis and definition of the system logical architecture are carried out. Secondly, the derived requirements of the system logical architecture design are identified. Finally, the SysML and FACE [4] Profile logical architecture models are transformed into AADL logical architecture models. Logical architecture design modeling is mainly to model and design the logical composition of the complex real-time embedded systems, which use the way of logical components to represent the system composition, and assign the functions in the functional architectures to the logical components. BDD diagrams are used to describe the composition relationship of the system, and the topmost block represents the system. Other blocks represent logical components or subsystems, and ports on blocks are used to represent data exchange ports for logical components. Create an interface package describing the data exchange port in the corresponding package in the logical architecture. The specific data modeling of the data exchange ports is carried out by using FACE Profile. By selecting the port type of the logical component as the data established by the FACE data model element, implement FACE data model and port association. The IBD diagrams are used to describe the interaction between the top-level logical components of the system and the data interaction between the sub-components within each top-level logical component. A connection Connector represents a data connection between logical components (represented by Property). The IBD diagrams are used to describe the allocation relationship between functions in the functional architecture and logical components in the logical architecture. In the BDD diagrams, the Blocks that represent functions are dragged into the diagram in the form of property. In the same way, the blocks of logical components are dragged into the diagram. When the models are relatively complex, the form of traceability matrix is used to describe the allocation relation between functional elements and logical components, and the dynamic behavior of logical entities is described through the state machine model based on logical entities to verify the dynamic behavior of logical architectures. 2.3 Physical Architecture Design Modeling Method Design physical architectures based on logical architectures. Firstly, define physical composition, including establishing physical sets, defining physical entities, determining mapping relationship between physical entities and logical entities, transformation of performance indexes to physical indexes, and allocation of physical indexes. Then, the interface analysis and definition of the system physical architectures are carried out. Secondly, the derived requirements of the system physical architecture design are identified. Finally, the SysML and MARTE [5] Profile physical architecture models are transformed into AADL physical architecture models. Physical architecture design modeling will introduce MARTE, use the elements in MARTE to specifically define the hardware and software composition and distribution relationship of embedded systems, and use BDD diagrams to describe the composition relationship of the system. The topmost block represents the system, and other blocks represent physical components or subsystems. The port on the block is used to represent the data exchange port of the physical component and connection is used to describe the

4

H. Ji et al.

system component composition relation. Blocks are used to represent the system and subsystem, MARTE elements are used to define the hardware and software composition of subsystem, and its internal composition relationship is represented in the IBD of the block. If property represents specific hardware and software, its type is defined by MARTE element. If property represents a subsystem, its type is the subsystem type defined by block. Allocate is used to describe the hardware or software allocation relationship between MARTE elements. Traceability matrix is used to describe the allocation relationship between logical architecture and physical architecture. 2.4 Research on Model Transformation Method According to the transformation methods, model transformation can be divided into model-to-model transformation and model-to-code transformation. The former includes manual model transformation, relational model transformation, graph model transformation, structural model transformation, metamodel transformation and other transformation, while the latter includes access-based model transformation and template-based model transformation. QVT is a model transformation standard defined by OMG. ATL is a model transformation language based on metamodel transformation method developed by INRIA in France. Kermeta is a model transformation language developed by INRIA Triskel Team in France, which can describe the structure and behavior of metamodel. GreAT is a way to apply graphic transformation and rewriting techniques to the process of model transformation. ATL and Kermeta are commonly used in model transformation of AADL models. Some research practices have also been done on OMG and AADL model transformation: The UML models marked with domain-specific stereotypes are transformed into AADL models. The non-functional property analysis is carried out based on the transformed AADL models, which makes the AADL models optimized, then the executable codes are automatically generated based on the optimized AADL models. Since SysML models, FACE Profile models, MARTE Profile models and AADL models are heterogeneous models, in order to realize the automatic transformation of SysML models, FACE Profile models and MARTE Profile models into AADL models, SysML models, FACE Profile models, MARTE Profile models and AADL models should be implemented to isomorphism under the same meta-metamodel system. Then semantic mapping and syntax transformation are carried out. The first problem to be solved in the transformation of heterogeneous models is to implement these models to isomorphism under the same meta-metamodel system. To define the metamodels of SysML models, FACE Profile models, MARTE Profile models and AADL models through the same meta-metamodel. SysML metamodels, FACE Profile metamodels, MARTE Profile metamodels and AADL metamodels are constructed through MOF [6]. The above models are simultaneously in the MOF meta-metamodel system, so that different modeling languages can be carried out semantic mapping in the same environment. Then define the semantic mapping rules for the SysML subset metamodel and the AADL subset metamodel at the M2 metamodel layer [6], and construct the concrete syntax for the AADL subset metamodel, which can be automatically implemented by the EMF [7] framework.

An Architectural Design and Architectural Transformation Method

5

Using EMF technology, an Ecore [7] metamodel is developed in Eclipse, which is used to describe the XMI [8] file of complex real-time embedded systems functional architecture based on SysML. The Ecore model generates a parser that reads the SysML model structure representing the functional architecture from the XMI file to create an EMF model in Eclipse. By traversing the EMF model corresponding to the functional architecture SysML model to create the mapping of EMF model elements to AADL elements. On the basis of the transformation rules, firstly create the component corresponding to the AADL object and EMF to AADL mapping relationship, secondly use the model connector to establish the connection between each component, AADL functional architecture models are obtained. The model transformation method flow chart is shown in Fig. 1.

Fig. 1. The model transformation method flow chart.

Similarly, the logical architecture models of SysML and FACE Profile, the physical architecture models of SysML and MARTE Profile are transformed into the AADL logical architecture models and AADL physical architecture models respectively. The representative model transformation rules in the architectural models are shown in Table 1.

6

H. Ji et al. Table 1. The representative model transformation rules.

Architecture categories

SysML and extended profile model elements

AADL model elements

Functional architecture

Block

Abstract Type Abstract Implementation

Port

Abstract Feature of Abstract Type

Property

Abstract Subcomponent in Abstract Implementation

Logical architecture

Physical architecture

Connection

Feature Connection

Block

System Type System Implementation

Port

Abstract Feature of System SubComponent

Property

System SubComponent in System Implementation

Connection

Feature Connection

Data Model

Package

Conceptual Query

Data

Conceptual Composite Query

Data Data Implementation

Conceptual Query Composition

Data subcomponent

Logical Query

Data or data extends…

Logical Composite Query

Data or data extends… Data implementation

Logical Query Composition

Data subcomponent

Platform Template

Data or data extends… Data implementation

Platform Composite Query

Data or data extends… Data implementation

Platform Query Composition

Data subcomponent

Block

System Type System Implementation

Port

Data port of System SubComponent

Property

System SubComponent in System Implementation

Connection

Port Connection (continued)

An Architectural Design and Architectural Transformation Method

7

Table 1. (continued) Architecture categories

SysML and extended profile model elements

AADL model elements

hwProcessor

Processor

ProcessingResource

Virtual Processor

hwMemory

Memory

hwBus

Bus

CommunicationMedia

Virtual Bus

hwDevice

Device

DataType

Data

swMutualExclusionResource

Data

swSchedulableResource

Thread Thread Group

memoryPartition

Process

flowPort

Data Port

Nfp &NfpConstraint

Property set

Allocate

System Binding

3 Conclusion SysML is the standard modeling language of system engineering. From the early requirement capture to the final implementation of complex real-time embedded systems, if only SysML modeling is used, the high-level design of the system can only be completed, and the requirements of the complex real-time embedded systems related to software and hardware cannot be described clearly. Therefore, it is proposed to use FACE Profile and MARTE Profile to supplement SysML. In this way, based on the original metaclass and stereotypes of UML/SysML and extended Profiles, the metamodels and formal definition of FACE Profile and MARTE Profile are given. It provides support for the complex real-time embedded systems functional architecture, logical architecture and physical architecture modeling. Based on the business process and transformation method proposed in this paper, the transformation tool of SysML models, FACE Profile models and MARTE Profile models into AADL models will be implemented and integrated into the existing SysML modeling tool. Using EMF framework technology and Eclipse plugin technology to achieve the architecture transformation prototype tool plug-in, which realizes automatic transformation from SysML models, FACE Profile models, MARTE Profile models into AADL models, effectively improves the efficiency and accuracy of model transformation.

8

H. Ji et al.

References 1. The Object Management Group: OMG Model Driven Architecture-The Architecture of Choice for a Changing World (2011) 2. The Object Management Group: OMG Systems Modeling Language (OMG SysML™) Specification Version 1.6. OMG Available Specification (2019) 3. SAE Aerospace: SAE AS5506D: Architecture Analysis and Design Language V2.3 (2022) 4. The Open Group: FACE Technical Standard, Edition 3.0, Open Group Standard, (2017) 5. The Object Management Group: UML Profile for MARTE: Modeling and Analysis of RealTime Embedded Systems Version 1.2. OMG Available Specification (2019) 6. The Object Management Group: Information technology – Object Management Group Meta Object Facility (MOF) Core. OMG Available Specification (2014) 7. Steinberg, D., Budinsky, F., Paternostro, M.: EMF: Eclipse Modeling Framework, 2nd edn. Addison-Wesley Educational Publishers Inc. (2008) 8. XML Metadata Interchange (XMI). OMG Available Specification (2014)

A Generalized Reuse Framework for Systems Engineering Gan Wang(B) Dassault Systèmes, Herndon, VA 20171, USA [email protected]

Abstract. Reuse in system development is a prevalent phenomenon. However, how reuse is applied varies widely. The Generalized Reuse Framework is a strategic reuse model for systems engineering management in product development that addresses both investment and leverage of reuse through two interrelated and interacting processes: Development with Reuse (DWR) and Development for Reuse (DFR). This chapter summarizes the latest development of this framework by providing the taxonomic definition of DWR and DFR and analyzing the decision processes for reuse as applied to incremental development and product line engineering. It also describes how the framework is applied to the revision of the Constructive Systems Engineering Cost Model (COSYSMO), a parametric cost estimating model for systems engineering. With use case scenarios, it illustrates the approach to apply the framework and to quantify the economic impact of reuse vis-à-vis investment strategies. Keywords: Reuse · Systems Engineering · System Development · Modeling · Parametric Estimating · Cost Estimation and Analysis · Project Planning

1 Introduction As industry embarks on an accelerated digital engineering (DE) transformation journey aiming for more efficient and effective capabilities for developing and sustaining systems, organizations seek to invest in digital infrastructure, model-based business processes, and a digitally capable workforce. At the same time, they continue to search for ways to quantify returns on investment. As widely accepted in the SE community, reuse is essential and sometimes even imperative for today’s system development (De Weck, et al, 2003; Clements, 2015; Le Put, 2015). Reuse is fundamentally driven by economic necessities and ever-mounting pressure to deliver value and profitability to shareholders. A common rationale is costsaving through reduced work and improved quality (Nazareth and Rothenberger, 2004; Selby, 1989, 2005). However, a more recent focus is the speed of delivery and time to market. In his keynote speech, Jan Bosch (Bosch, 2014) pointed out a relatively contemporary trend of modern systems from “built to last” to “built to evolve” to adapt to a faster pace of technology change and user expectations. Reuse, especially when © The Author(s), under exclusive license to Springer Nature Singapore Pte Ltd. 2023 D. Krob et al. (Eds.): CSD&M 2023, LNEE 1085, pp. 9–24, 2023. https://doi.org/10.1007/978-981-99-6511-3_2

10

G. Wang

strategically planned, can be a fundamental enabler for the evolutionary approach to system development. Reuse can be opportunistic in that a designer or developer spends effort searching and discovering reusable resources when the need arises inside and outside their organization and then, if successful, attempts to use the artifacts they find. For example, someone can do a Google search for freeware and lift a code segment that appears to fit a purpose. In software development, it is sometimes called “code scavenging.” The outcome is almost inconstant depending upon what is available. In some cases, the reused code has to be modified. In almost all cases, its behavior has to be tested and verified. If anything fails, the developer has to debug the issues and fix the defects. This ad hoc reuse approach involves a process of discovery, assessment, modification, integration, and testing. Its main effort focuses on leveraging benefits through opportunity. For smaller efforts, this approach can be successful. But it does not scale well. The reusability is generally low and uncertainty high, especially for larger and more complex systems. On the other side of the spectrum, reuse is planned and strategic (Kim and Stohr, 1998; Hillhouse, 2011). In this case, the developer proactively and strategically invests in reusable resources through explicit reuse processes and standards. A major focus is the up-front investment effort to make an effort easier when the actual reuse occurs later. Examples that come to mind include object-oriented software development. An object class (typically called base class) is defined to instantiate other classes of objects (called derived classes), which inherit the properties of the base class. Another strategy is to create libraries that encapsulate particular objects and functionalities that can be used in multiple applications through a set of application programming interfaces (APIs). Modern programming languages like Python and MATLAB contain large libraries of reusable objects and patterns. Developed through collaboration with the University of Southern California (USC) Center for Systems and Software Engineering (CSSE) and based on a series of studies (Wang, et al, 2014, Wang, 2016), the Generalized Reuse Framework (GFR) defines two interrelated and interacting reuse processes: • Development with Reuse (DWR): a set of system development activities that focus on gaining benefits from utilizing or leveraging previously developed reusable artifacts, either in a planned process or an ad hoc manner • Development for Reuse (DFR): a set of system development activities dedicated to developing reusable artifacts for future usages, generally in a planned manner or through an investment effort DFR and DWR represent the two foundational processes that bridge reuse in system development projects or, in a broader sense, for any efforts that deliver products or services. The two processes are distinguished only by intent – production and consumption of reusable resources. DWR focuses on benefits gained from using reusable resources. The basic assumption is that DWR saves labor and improves the product quality at the same time for the system that leverages these resources. DFR, on the other hand, aims to create reusable products for future usage. Acting as a producer, the DFR process feeds reusable resources into the DWR process that consumes them in its development effort. See Fig. 1.

A Generalized Reuse Framework for Systems Engineering

11

Fig. 1. The Generalize Reuse Framework consists of two interactive processes: the DFR process feeds reusable resources into the DWR process that leverages these resources

The basic premise, however, is that DFR may incur additional upfront costs than without such a consideration to gain the benefits in DWR. But in the aggregate, it will save cost from the lifecycle point of view. Table 1 contrasts the major characteristics of the two processes. Table 1. Contrasting two reuse processes – “Development with Reuse” and “Development for Reuse” Development with Reuse

Development for Reuse

Role

• Consumer

• Producer

Purpose

• Consumption of reusable resources

• Production of reusable resources

Goal

• Improvement of product quality • Cost savings • Improved speed of delivery or time to market

• Investment for future benefits

Challenges

• Discovery of what to reuse • Plans for how to reuse • Decisions on how to tailor and integrate • Design for reusability • Means to verify

Reusability

• If ad hoc, then generally low • If planned, then generally high

• Generally high

This process model addresses reuse as a central consideration for development strategy as applied to agile SE, product line engineering, and the evolution of system capability through incremental development. It assumes that a product or product line (whether it is a vehicle, aircraft, electronics, or software) is developed by a series of projects, each of which produces several articles or baseline versions. In each article or version release, there is a mix of the DWR and the DFR contents. With careful planning, the DWR and DFR content mix changes favorably with an increasing number of articles produced or release versions deployed, while the total incurred project effort (red line) decreases, as shown in Fig. 2. As the product line matures, the percentage of the DFR content decreases while relative DWR content increases. This phenomenon can be viewed as the investment paying off over time.

12

G. Wang Total Effort

100

% Effort

DWR

DWR DWR

DWR

DFR DFR DFR 0

1

2

3

DFR 4

# of Articles in the Product Line

Investments in Development for Reuse (DFR) are leveraged to reduce Product Line Cost

Fig. 2. A mix of DWR and DFR efforts in a project and the decreasing levels of DFR effort in the successive article releases of a project line

2 The Generalized Reuse Framework 2.1 Reusable Resources What can be reused? A simple answer is almost everything. From an engineering perspective, however, it is the outputs from the SE processes that can be reusable, which include elements of the realized system. Then the question is, how do we express them? We define a reusable resource as a collection of system artifacts that represent certain attributes of the system. System artifacts are physical and functional components (e.g., a piece of hardware, a software module) of a system, along with all the associated engineering and design data that specify the system at different stages of its life cycle. A design specification can be considered as a collection of system attributes represented in requirements and logical, functional, and physical architecture descriptions. It can be functional or non-functional (performance) based. For example, a system attribute can be a system interface that is realized with a physical hardware connection or a software object that pulls or pushes data. Or it can be a function depicting a behavior in terms of an input and output relationship and that is realized by a hardware control logic or implemented by a software algorithm. Together, these system attributes represent what the end system is and how it functions. As a system attribute is realized through a development life cycle, a set of system artifacts are produced and, over time, culminate in the actual system built and deployed. Reversely, a system is simply an integrated collection of system artifacts developed that, together, satisfy the specified system attributes. For definitions of the GRF process coming up next, we use the term system attribute to represent all the reusable resources. 2.2 The Reuse Process Development with Reuse. The DWR consists of six (6) categories, as shown in Table 2 below.

A Generalized Reuse Framework for Systems Engineering

13

Table 2. Definitions of the DWR categories New

A system attribute that is new or unprecedented, which requires developing from scratch; or from previously defined system design or constructed product components but requiring near-complete changes in system architecture as a result of that requires developing from scratch; or from previously defined system design or constructed product components but requiring near-complete changes in system architecture due to modified or extended system functionalities

Design Modified

A system attribute that is designed and developed by leveraging previously defined system concept, functional and logical reference architecture; or from previously designed physical architecture or constructed product components that require significant design and implementation changes or refactoring but without major changes in intended system functionality

Design Implemented

A system attribute that is implemented from an inherited, completed system design or a previously constructed product component that may require only limited design changes in the physical architecture to the extent that it will not impact or change the basic design, but that may require reimplementation of the component

Adapted for Integration A system attribute that is integrated by adapting or tailoring (through limited modification of interfaces) of previously constructed or deployed product components without changes in the core architecture, design, or physical implementation (except for those related to interface), so that the adapted element can be effectively integrated or form fit into the new system. The change effort required is less than that of the Design Implemented category. Removing a system element from a previously developed or deployed system baseline is also included in this category Adopted for Integration A system attribute that is incorporated or integrated from previously developed or deployed product components without modification, which requires complete integration, assembly, test and checkout activities, as well as system-level V&V testing. This is also known as “black-box” reuse or simple integration Managed

A system attribute that is inherited from previously developed and validated product components without modification or that the integration of such an element, if required, is through significantly reduced V&V testing effort by inspection or utilizing provided test services, procedures, and equipment (so called “plug and play”). Most of the SE effort incurred is a result of technical management

The terminology for the category names is chosen in such a way that, colloquially, one can say a system attribute (e.g., requirement, interface, etc.) is “New,” “Design Modified,” “Design Implemented,” and so forth. The DWR categories capture the amount of work required to realize a system attribute in the final system by leveraging those system artifacts available for reuse at the time.

14

G. Wang

Fig. 3. Typical entry points for the work required by the DWR categories relative to the system “V” model, as a reference for different maturity level of the reusable resources

From a lifecycle perspective, this work typically corresponds to the lifecycle stage in which relevant artifacts are available, as shown in Fig. 3. The arrows indicate the typical entry point for most of the development work. For example, “Adopted for Integration” typically commences during the integration, test, and verification phase as it is possible to leverage artifacts from existing system implementation. The concept is, in a sense, similar to that of the Technical Readiness Level or TRL. The use of system “V” model provides a convenient reference for the maturity of the system attributes under the reuse consideration. In other words, an attribute deemed “Adopted” must have sufficient maturity to be “Adopted” or integrated without any modifications. However, the DWR process is not limited to waterfall development and can apply other development models, such as agile development processes. Development for Reuse. The DFR process consists of five (5) categories, as shown in Table 3 below. Table 3. Definitions of the DFR categories No DFR

No development for reuse within the planned work scope

Conceptualized For Reuse This category includes a set of front-end SE activities that produce conceptual, contextual, logical and/or functional architecture elements intended for future reuse, that must be further developed through a series of detailed design, implementation, verification and validation testing activities to realize the final deployable product Designed For Reuse

This category includes a set of front-end system design activities that produce a complete system design or physical architecture elements intended for future reuse, that must be further developed through a series of implementation, integration, and verification and validation testing activities to realize the final deployable product

Constructed For Reuse

This category includes a set of system development activities that produce a physical product or component intended for future reuse, that has been implemented and independently verified through verification testing but has not been deployed or used in an end system. These activities include required efforts at all levels of design and development, just short of final system-level integration, transition, verification, and validation testing

Validated For Reuse

This category includes all system development activities that produce an end physical product or component intended for future reuse and operationally validated through its use in an end system

Similarly, as in the case of DWR, Fig. 4 shows the general exit points for the DFR process relative to the system “V” model for different categories of reusable artifacts.

A Generalized Reuse Framework for Systems Engineering

15

For example, if the development activity stops after the Detailed Design phase, the reusable artifacts generated would be at the level of “Designed for Reuse.” On the other hand, if a system component has been built and united tested, it should be categorized as “Constructed for Reuse”, ready to be integrated into a future DWR process. As in the case of DWR, the use of “V” model is only a reference for reuse maturity. The DFR process is not limited to waterfall development and can apply other development models, such as agile develop processes.

Fig. 4. The exit points of the DFR categories relative to the “System V” model, as an indication for different levels of reuse maturity

The DFR categories capture the work required to develop reusable artifacts at varying maturity levels. The DFR process can be a separate investment effort or occur in the same project as the DWR process. In the latter case, the same system attribute should be classified twice – once for DFR and second for DWR in an appropriate category. 2.3 GRF Usage Scenarios We consider four basic scenarios of reuse strategy: reuse of 1) concept definition; 2) system design; 3) system implementation; and 4) valided system component. This achieved by managing different system artifacts between the DWR and the DFR processes. Figure 5 shows the four classifications in the DFR space and the logical paths to the respective DWR categories, depending on the reusability the system attributes or the amount of modifications required when applied to the DWR space. For example, if the system design is completely for a system attribute and it is classified as a “Designed for Reuse” in the DFR space, it can classified as “Design Implemented” for the DWR effort and we can directly proceed to implementation, if no additional design changes are needed. Otherwise, if design changes are needed, we must fall back to Conceptualized for Reuse and follow the logical path accordingly. Importantly, the question should be asked in the reversed direction. If certain reusability is desirable in the DWR process, what level of investment is required for a DFR process? This thought process is critically important for systems engineers and product managers in planning strategic reuse. The decision process associated with each case can serve as a guideline for a product line manager to consider in planning the work scope and estimating the development effort, both from an investment angle and leveraging that investment. This thought process is critically important for systems engineers and product managers in planning strategic reuse.

16

G. Wang

Fig. 5. Relationships of the DFR and DWR categories

3 An Illustrative Example – Application of the Generalized Reuse Framework to Cost Estimating and Analysis Cost estimating and analysis is crucial to all modern systems engineering practices. It is an integral part of system development and acquisition. As a fundamental pillar for economic analysis and business decision-making, cost estimation is critical in evaluating the merit of system architecture and provides the essential criteria for design trade space. Parametric estimating is based on statistical analysis of historical data. In essence, it uses parametric equations between cost (and effort) and one or more parameters. These parameters are derived from the characteristics of the system under estimation and may be physical, performance, operational, programmatic, or cost in nature. They are the independent variables into the equation and commonly known as cost drivers. The parametric equation is commonly known as Cost Estimating Relationship (CER). It is based on the statistical inferences of multiple similar systems or development efforts. Its output is cost or effort required for development of the system. Parametric estimating is commonly recognized as one of the most effective and the most trusted cost estimating methods. It is often preferred by the source selection authorities for system acquisition. 3.1 COSYSMO COSYSMO or the Constructive Systems Engineering Cost Model (Valerdi, 2005) developed at the University of Southern California, is a parametric model for estimating the end-to-end systems engineering and integration (SE&I) effort required in developing and deploying a system. Evolved from COCOMO, or the Constructive Cost Model (Boehm, 1981, Boehm et al., 2000), COSYSMO defines a CER that estimates the SE&I effort in a development project using four sizing parameters, also known as size drivers: • System requirements (REQ) • System interfaces (INT)

A Generalized Reuse Framework for Systems Engineering

17

• Critical system algorithms (ALG) • Operational scenarios (SCN) The nominal effort is further adjusted by fourteen effort multipliers, also known as cost drivers, representing the product and project environment and complexity factors. Mathematically, the effort, under a nominal schedule, is described as a function of weighted counts of the four size drivers Eq. (1):  E 14   PMNS = A · (we,k e,k + wn,k n,k + wd ,k d ,k ) · EMj (1) k

j=1

where, PMNS = effort in Person Months (Nominal Schedule) A = calibration constant derived from historical project data k = {REQ, IF, ALG, SCN} wx = weight for “easy,” “nominal,” or “difficult” size driver Fx = quantity of “k” size driver E = represents (dis)economies of scale EMj = effort multiplier for the jth cost driver; the geometric product results in an overall effort adjustment factor to the nominal effort. On an intuitive level, the weighted sum term in the equation above describes how “big” a system is and represents the “size” of the job for the development effort. We call it the “system size,” which aggregates the effect of four size drivers into a single quantify, with a unit of measure called “eReq” or equivalent requirements. The size drivers are each counted at three levels of difficulty. For a detailed description of the model, including the definitions of the size and cost drivers, as well as the quantitative aspects of its CER, please refer to (Valerdi, 2005). The remaining discussion in this section assumes the reader is familiar with the basic model definition. This model definition, known as COSYSMO version 1.0, does not consider reuse. As represented in Eq. (1), the CER implicitly assumes that all system developments start from scratch – not a very realistic and practical situation in today’s world. The lack of reuse semantics proved to be problematic in practical applications. It severely affects the estimating accuracy and cost realism (Wang, et al, 2008). An initial effort was to provide a formal construct for reuse similar to the DWR definition today (Wang, et al, 2010) and to augment the COSYSMO model definition. Practical applications of this extended COSYSMO proved effective and significantly improved the estimating accuracy. Figure 6 compares a set of historical project data, collected and validated in COSYSMO (Wang, et al, 2008), with two scatter plots showing the same set of projects captured before and after the reuse extension. Figure 6(a) shows the projects captured in COSYSMO version 1.0, without consideration of reuse and there is no distinctive trend observed. Figure 6(b) shows the same data set, now captured with an application of GRF, and the data converges and displays a distinct trend. Additional studies (Wang, et al., 2011, 2013–14) expanded the model to account for the entire scope of reuse – both the investment and the leverage of reusable resources – leading to the GRF today.

18

G. Wang

(a) Without consideration of reuse and all size drivers are effectively counted as new

(b) With consideration of reuse and size drivers are classified according to respective reuse categories

Fig. 6. Scatter plots of the same dataset representing a group of historical system development projects, before (a) and after (b) implementing a reuse extension in COSYSMO

3.2 The GRF-Based Cost Estimating Relationship The Generalized Reuse Framework extends the COSYSMO model definition to account for both the efforts of DWR and DFR. Thus, better characterizes the modern system development process and as a result, significantly improves the fidelity of the estimated cost. The generalized reuse framework inherently implies two parallel efforts in a development project, each driven by the DWR and DFR processes. Therefore, the total project effort is the sum of the two, as below: PHTotal = PHDWR + PHDFR where, PHTotal = total SE effort in person-hours for the entire project PHDWR = total SE effort in person-hours spent on the DWR process

(2)

A Generalized Reuse Framework for Systems Engineering

19

PHDFR = total SE effort in person-hours spent on the DFR process In essence, PHDWR is the total effort dedicated to developing the end system with benefit of reuse. It is less than what it would be if it started from a “clean slate”. PHDFR is the effort devoted to developing reusable artifacts that could be reused either within the same project or in future projects. Thus, the total effort can be expressed as EDWR EDFR PHTotal = ADWR · SSDWR · CEMDWR + ADFR · SSDFR · CEMDFR

(3)

where, SS represents the system size under development in the DWR and the DFR processes, respectively. It is with the same unit of measure of “eReq” or equivalent requirements, as in Eq. (1). The respective system size is expressed mathematically as     wr (we,k e,k + wn,k n,k + wd ,k d ,k ) (4) SSDWR = k

and SSDFR

r

⎞ ⎛   ⎝ = wq (we,k e,k + wn,k n,k + wd ,k d ,k )⎠ k

(5)

q

where, Fx = quantity of “k” size driver, accounted for in the DWR process Ψ x = quantity of “k” size driver, accounted for in the DFR process k = {REQ, IF, ALG, SCN} e = {Easy, Nominal, Difficult} r = {New, Design Modified, Design Implemented, Adapted for Integration, Adopted for Integration, Managed} q = {No DFR, Conceptualized for Reuse, Designed for Reuse, Constructed for Reuse, Validated for Reuse} wx = weight for “easy,” “nominal,” or “difficult,” for the respective size driver wr = weight for defined DWR levels of the respective size driver wq = weight for defined DFR levels of the respective size driver ADWR = calibration constant for DWR, typically derived from historical project data ADFR = calibration constant for DFR, typically derived from historical project data E DWR = nonlinearity for the DWR productivity curve, representing a diseconomy of scale E DFR = nonlinearity for the DFR productivity curve, representing a diseconomy of scale CEM DWR = composite effort multiplier for DWR CEM DFR = composite effort multiplier for DFR

20

G. Wang

Putting it all together, we can express the CER for the total project effort, including both the DWR and DFR efforts, as

EDWR    wr (we,k e,k + wn,k n,k + wd ,k d ,k ) · CEMDWR PHTotal = ADWR · r

k

⎛

⎡

⎞⎤EDFR   ⎝ +ADFR · ⎣ wq (we,k e,k + wn,k n,k + wd ,k d ,k )⎠⎦ · CEMDFR k

q

(6) This cost estimating relationship captures the total project effort, including the part for investment and the part with the benefit of reuse. It shows that a development project may contain both the DFR and DWR efforts, in different proportions. Reversely, a system attribute may purposefully be developed in both the DFR and the DWR processes. When counting the size drivers for a system or a project, we classify them in the corresponding DWR and DFR categories, respectively, to accurately account for the collective effort. For example, a critical system algorithm may be implemented as part of a standard library and it would be classified as Constructed for Reuse in the DFR process. It can then be used in the same project and would be classified as Adopted in the DWR process, if it can be directly integrated into the end system. As any experienced systems engineer would say, “Not all requirements are created equal!” COSYSMO extended by the GRF is a powerful proof of that statement. 3.3 The DWR and DFR Weights The reuse weight values in Eq. (6) were obtained through a series of wide-band Delphi Analyses and further validated with the dataset shown in Fig. 6. They are elaborated next. 3.3.1 The DWR Weights Table 4 provides the derived values for the DWR category weights. The percentage values in the first row are the relative weights for the six DWR categories, with New at 100% and other categories at an incrementally lower level. Mathematically, they are the numerical values for the coefficients, wr , in Eq. (6). At an intuitive level, they represent the partial set of SE activities required to realize a size driver (REQ, IF, ALG, or SCN) in the end system due to leveraging reuse, relative to the complete set of end-to-end activities corresponding to New. The rest of the 24 (4x6) decimal values in the table correspond to the individual DWR weights for each of the four size drivers, in respective rows, at the nominal level of difficulties. A graphical representation is provided in Fig. 7 that gives an intuitive impression of the relative weight distributions for the four size drivers in each of the six reuse categories. The height of the bars corresponds to the decimal values in the table above in the respective reuse categories. The downward trend for each of the size drivers (shown in a different color) represents a decreasing level of required development effort due to the benefit of increasing levels of reuse (from New to Managed), as previously elaborated.

A Generalized Reuse Framework for Systems Engineering

21

Table 4. The numerical weights of the six DWR categories for each of the four COSYSMO size drivers at the nominal level of difficulty New

Modified

Impl’ted

Adapted

Adopted

Managed

100.00%

66.73%

56.27%

43.34%

38.80%

21.70%

System Requirements

1.00

0.67

0.56

0.43

0.39

0.22

System Interfaces

2.80

1.87

1.58

1.21

1.09

0.61

Critical Algorithms

4.10

2.74

2.31

1.78

1.59

0.89

Operational Scenarios

14.40

9.61

8.10

6.24

5.59

3.13

When resolving the weight values for the three-dimensional weighted sum term in Eq. (6), we get four sets of 18 (3 × 6) weight values, one for each of the four size drivers, or 72 values in total. This is the result of expanding the six DWR categories to consider all three levels of difficulties at the same time.

DWR Category Weights 16.0 14.0 12.0 10.0 8.0 6.0 4.0 2.0 0.0 New

Design Design Adapted for Adopted for Modified Implemented Integration Integration Nominal Requirements Nominal Interfaces Nominal Algorithms Nominal Scenarios

Managed

Fig. 7. The graphical representation of the six DWR category weights for each of the four COSYSMO size drivers at the nominal level of difficulty

3.3.2 The DFR Weights Similarly, the values for the DFR weights are listed in Table 5. Mathematically, these values define the numerical values for the coefficients wq in Eq. (6). At an intuitive level, however, they indicate an increasing level of SE effort required to realize a size driver (REQ, IF, ALG, or SCN) to a higher level of reusability. In particular, the percentage

22

G. Wang

values in the first row represent the derived DFR category weights, with 0% for No DFR and other categories at increasing levels up to 94.7% for Validated for Reuse. Table 5. The numerical weights of the five DFR categories for each of the four COSYSMO size drivers at the nominal level of difficulty Nom. Weights

No DFR

Conceptualized for Reuse

Designed for Reuse

Constructed for Reuse

Validated for Reuse

0.00%

36.98%

58.02%

79.15%

94.74%

System Requirements

1.00

0.00

0.37

0.58

0.79

0.95

System Interfaces

2.80

0.00

1.04

1.62

2.22

2.65

Critical Algorithms

4.10

0.00

1.52

2.38

3.25

3.88

Operational Scenarios

14.40

0.00

5.33

8.36

11.40

13.64

Figure 8 represents the DFR category weights for the four size drivers (No-DFR not represented). Each of the four groups represents the weights of a category for the four size drivers, each shown by different color bars. Once again, the height of the bars corresponds to the decimal values in the table above, in the respective reuse categories for all the drivers. Contrary to DWR, the upward trend in the graph, from Conceptualized for Reuse to Validated for Reuse, represents an increasing level of SE effort for all four size drivers.

DFR Category Weights 16 14 12 10 8 6 4 2 0 Conceptualized for Reuse

Designed for Reuse

System Requirements Critical Algorithms

Constructed for Reuse

Validated for Reuse

System Interfaces Operational Scenarios

Fig. 8. The graphical representation of the five DFR category weights for each of the four COSYSMO size drivers at the nominal level of difficulty

A Generalized Reuse Framework for Systems Engineering

23

After fully resolving the weight values for the three-dimensional weighted sum term in (2–2), we get four sets of 15 (3 × 5) weight values, one for each of the four size drivers, or 60 values in total. These values are the result of expanding the five DFR categories to consider all three levels of difficulties at the same time.

4 Conclusion Reuse is a fundamental feature of SE. However, only planned reuse with a proactive product strategy likely yields economic benefits. The Generalized Reuse Framework provides an effective tool for product-line managers and systems engineers to manage reuse in a system development effort. We provided the definitions of the DWR and DFR processes and showed how they can be applied to tradeoffs of incremental development strategies and reuse planning in product-line engineering for large-scale system development projects. We also described an application of this framework to cost estimating. Specifically, we describe an extension of COSYSMO model definition by applying the GRF, including the modified cost es-timating relationship with a set of coefficients calibrated by the reuse weights. The extended COSYSMO more closely captures actual system development processes, cost and efforts, and significantly increases the fidelity of the cost model and the accuracy of its estimates. With the competitive market environment and continuous drive for improved productivity and efficiency, reuse has become a primary consideration by business enterprises, not just a cost-saving measure but a strategic approach that can positively impact various aspects of system development, ultimately contributing to their success in the market. Systematically integrating reuse into the end-to-end systems engineering process is essential for maximizing the advantages it offers and realizing the promises of improved architecture understanding, better development de-cisions, increased agility and collapsed cycle time, and reduced lifecycle cost for the complex systems we develop today and tomorrow.

References Boehm, B.W.: Software Engineering Economics. Prentice Hall PTR (1981) Boehm, B., et al.: Software Cost Estimation with COCOMO II. Upper Saddle River, NJ, PrenticeHall (2000) Bosch, J.: Examining the need for change in strategy, innovation methods and R&D practices. In: Keynote, the 24th INCOSE International Symposium, Las Vegas, NV (2014) Clements, P.C.: Product line engineering comes to the industrial mainstream. In: Proceedings of the 25th Annual INCOSE International Symposium. Seattle, WA (2015) De Weck, O., Suh, E.S., Chang, D.: Product family and platform portfolio optimization. In: Proceedings of the ASME Design Engineering Technical Conferences – Design Automation (2003) Hillhouse, B., Ishigaki, D.T.: Strategic Reuse: A Fundamental Approach for Success in E/E Engineering. IBM Rational webinar (2011) Kim, Y., Stohr, E.A.: Software reuse: survey and research directions. J. Manag. Inform. Syst. 14(4), 113–147 (2015)

24

G. Wang

Le Put, A.: Systems Product Line Engineering Handbook. Association Francaise d’Ingenierie Systeme (2015) Nazareth, D.L., Rothenberger, M.A.: Assessing the cost-effectiveness of software reuse: a model for planned reuse. J. Syst. Softw. 73(2), 245–255 (2004) Selby, R.W.: Quantitative studies of software reuse. In: Biggerstaff, T.J., Perlis, A.J. (eds.) Software reusability: vol. 2, applications and experience, pp. 213–233. ACM, New York, NY, USA (1989). https://doi.org/10.1145/75722.75733 Selby, R.W.: Enabling reuse-based software development of large-scale systems. IEEE Trans. Softw. Eng. 31(6), 495–510 (2005) Valerdi, R.: The Constructive Systems Engineering Cost Model (COSYSMO), PhD Dissertation, University of Southern California (2005) Wang, G., et al. COSYSMO reuse extension. In: Proceedings of the 18th INCOSE International Symposium. Utrecht, the Netherlands (2008) Wang, G., Valerdi, R., Fortune, J.: Reuse in systems engineering. IEEE Syst. J. 4(3), 376–384 (2010) Wang, G., Rice, J.: Considerations for a generalized reuse framework for system development. In: Proceedings of the 21st INCOSE International Symposium. Denver, CO (2011) Wang, G., Valerdi, R., Roedler, G., Pena, M.: Quantifying systems engineering reuse – a generalized reuse framework in COSYSMO. In: Proceedings of the 23rd INCOSE International Symposium, Philadelphia, PA (2013) Wang, G., Valerdi, R., Roedler, G., Pena, M.: A generalized systems engineering reuse framework and its cost estimating relationship. In: Proceedings of the 24th INCOSE International Symposium. Las Vegas, NV (2014) Wang, G.: The generalized reuse framework – strategies and the decision process for planned reuse. INCOSE Int. Symp. 26(1), 175–189 (2016)

The Research on the Task Scheduling and Optimization Technology for Flight Tests Bei Tian1 , Gang Xiao1(B) , Jun Hong1,2 , and Yu Shen1 1 School of Aeronautics and Astronautics, Shanghai Jiao Tong University, 800 Dongchuan RD,

Minhang District, Shanghai 200240, China [email protected] 2 COMAC Shanghai Aviation Industrial (Group) Co., Ltd., 5 Yunjin RD, Xuhui District, Shanghai 200232, China

Abstract. The flight test plays an important role in aircraft development. For flight tests, the flight test schedule directly determines the flight test duration (FTD) and flight test cost. To generate an effective flight task schedule, the task scheduling problem for flight tests, which refers to searching for the optimal arrangement solution for a given flight test task requirement, is proposed and studied in this paper. First, a description and classification of the task scheduling problem for flight tests are presented. Based above, the mathematical model for the basic problem is established. Then, the solving algorithms including the exact and approximate methods are reviewed. Finally, numerical experiments on the task instances of different scales are conducted. Keywords: Flight test · Task scheduling · Combinatorial optimization · Mixed integer linear programming

1 Introduction To develop an aircraft, it needs to go through the process of requirement definition, preliminary design, detailed design, integration test, trial production, flight test, and production [1]. Among them, the aircraft manufacturer’s capacity to conduct flight tests represents its fundamental competency. Flight test refers to the various tests conducted under real flight environment conditions to obtain the aircraft function and performance data under a real environment [2]. The purpose of the flight test is, on the one hand, to evaluate the conformity of the design through the obtained data, to conduct the most rigorous, realistic, and comprehensive verification of whether the expected design requirement is met, and to provide a basis for refinement, improvement, and modification. On the other hand, it is to verify whether the aircraft meets the requirements of airworthiness regulations [3]. The flight test is an important stage that the aircraft must go through to obtain a type certificate (TC) and put it into operation. Due to the high complexity, high safety risk, high organizational difficulty, and high cost of the current flight test work, it is important to increase the safety and efficiency of civil aircraft flight tests in an intelligent and standardized way to improve flight test © The Author(s), under exclusive license to Springer Nature Singapore Pte Ltd. 2023 D. Krob et al. (Eds.): CSD&M 2023, LNEE 1085, pp. 25–36, 2023. https://doi.org/10.1007/978-981-99-6511-3_3

26

B. Tian et al.

management and technical level. As the duration and cost of the flight test are directly influenced by the flight test schedule, an efficient schedule for flight test tasks can more effectively mobilize flight test resources, lower flight test risks, and increase flight test effectiveness. Currently, scheduling tasks for flight tests is done manually and primarily relies on expertise. The main issues of this work mode are as follows: 1) There exists redundancy or vacancy in the actual execution process due to the flight test schedule is not optimal; 2) The constraints are not fully considered when scheduling the tasks, which results in invalid tests and re-testing work; 3) The relationship between multiple interests is not fully optimized and balanced, such as the relationship between flight test duration (FTD) and flight test intensity, consumption, etc.; 4) With the emergence of uncertainties in the flight test process, modifying and recompiling the test schedule creates a huge workload due to the lack of dynamic ability of modification for the schedule. Back in the early 1980s, the Dryden Flight Research Center of NASA developed the Automated Flight Test Management System (ATM) and proved that systems can significantly improve flight test efficiency [4]. In order to complete challenging test jobs in a limited amount of time, we think the industry has since investigated various cuttingedge technology in flight test schedule automatic management. However, there aren’t many studies and papers on this topic in the literature. And other traditional combinatorial optimization problems (COPs), such as the traveling salesman problem (TSP) [5], the job-shop scheduling problem (JSP) [6], and task scheduling in cloud computing [7], have been extensively researched in the literature, which provides us with some inspiration. In this paper, the scheduling problem for flight tests is studied and analyzed. Firstly, the description and classification of the problem are presented. The modeling approaches are analyzed and a MILP mathematical model is established. Then, optimization algorithms for solving the problem are presented. Finally, the case problem is solved by the established MILP model and GA. The remainder of the paper is structured as follows. Section 2 presents the classification and MILP model of the problem. In Sect. 3, the optimization algorithm is reviewed. In Sect. 4, the numerical experiments and discussions are presented. Finally, some conclusions and future work are drawn in Sect. 5.

2 The Problem Description 2.1 Problem Classification Since generating the flight test schedule is a complex task, there are different ways to classify it from different perspectives. Generally, the flight test scheduling problems can be subdivided into the following types, listed in Table 1. • R&D tasks scheduling, conformity verification tasks scheduling, and other task scheduling: R&D flight tests are carried out to freeze the aircraft’s configuration and verify the aircraft design index according to the aircraft design requirement and the aircraft status; The conformity verification flight test is to prove that the aircraft design meets the airworthiness standards, dedicated conditions, and equivalent safety requirements; Other flight tests include operational flight test, simulator flight tests, and operational flight tests, etc.

The Research on the Task Scheduling and Optimization Technology for Flight Tests

27

• Subject scheduling and test point scheduling: Test top-level flight test task scheduling refers to the process of arranging different flight test subjects to test aircraft. Flight test execution scheduling is the process of forming a task list after the top-level scheduling is completed, considering the transfer between test points. • Single configuration and flexible configuration scheduling: In single configuration scheduling, flight test tasks can only be assigned to specific test aircraft; Flexible configuration scheduling increases the flexibility of the test aircraft, i.e., a task can be assigned to any test aircraft in a specific set of compatible aircraft. • Single objective and multi-objective scheduling: Minimizing FTD, flight test intensity, task tardiness, flight workload, etc. are typical goals for flight test task scheduling problems. The multi-objective flight test task scheduling problems involve two or more single objectives. • Static scheduling and dynamic scheduling: Static scheduling means that the environment status does not change throughout the flight test execution process, i.e., once the schedule is determined, it does not change over time. Dynamic scheduling means that due to the changing factors in the flight test process, it is necessary to update the schedule to the current environment status.

Table 1. Classification of task scheduling in flight tests Classification standard

Types of scheduling

Source of scheduling requirement

R&D tasks scheduling conformity verification tasks scheduling other task scheduling

Task scheduling level

subject scheduling test point scheduling

Configuration of aircraft

single configuration scheduling flexible configuration scheduling

Scheduling objectives

single objective scheduling multi-objectives scheduling

Characteristics of the environment

static scheduling dynamic scheduling

2.2 Mathematical Model Before the presentation of the model formulation, the following parameters are listed below. 1. Parameters: n: total number of tasks m: total number of aircraft Ti : the i th task

28

B. Tian et al.

AC i : compatible aircraft set on which the task Ti can be processed TPi : precedent tasks set of task Ti . TFi : follow-up tasks set of task Ti . i, j: index of task, i, j = 1, 2, . . . , n k: index of aircraft, k = 1, 2, . . . , m ti : test duration of task Ti . ak : deployment time of aircraft k. tistart : available time for task Ti . It is equal to 0 when task Ti has no special requirement for start time tiend : estimated completion time for task Ti . It is Inf when task Ti has no special requirement for completion time L: a large positive number Zij : binary parameter denotes the task execution logic constraint between two tasks. It is equal to 1 if task Tj only can be processed after the completion of task Ti , 0 otherwise 2. Variables: si(k) : start time of task Ti (on aircraft k) ci(k) : completion time of task Ti (on aircraft k) ciTP : maximum completion time of all the precedent tasks of task Ti ckend : completion time of the last task on aircraft k nk : total number of tasks assigned on aircraft k Xik : binary variable that is equal to 1 if task Ti is assigned on aircraft k, 0 otherwise Yijk : binary variable that is equal to 1 if task Ti precedes task Tj on aircraft k, 0 otherwise The problem studied in this section is described as follows: Given m aircraft AC = {AC1 , AC2 , . . . , ACm }, n flight test tasks T = {T1 , T2 , . . . , Tn }. Each flight test task Ti must be performed after its predecessor flight task Tj ⊆ T (i = j) is completed. Each flight test task Ti can only be test flown on a set of specific test aircraft AC i ⊆ AC. The test aircraft are put into service in an orderly manner according to a certain interval. Therefore, the deployment arrival time of the test aircraft (k − 1)∗aT . Moreover, the following assumptions are met: • • • • • • • •

Each test aircraft can only execute one task at a time; Each task can only be scheduled once; Once a task has begun, it cannot be interrupted; The execution time and compatible test aircraft for each task are known in advance; The time interval between the first flight of each test aircraft is known; The execution logic of each task is known, and each task has a set of predecessors; The arrival time of the specified aircraft configuration is known; The combinable tasks are already optimized and do not need to be considered again in the scheduling process. Minimize: FTD = max ci

(1)

The Research on the Task Scheduling and Optimization Technology for Flight Tests

29

subject to:  k∈AC i

Xik = 1 ∀i

(2)

cik ≥ sik + ti ∀i, k

(3)

sik ≥ Xik ∗ak ∀i, k

(4)

  ci ≤ sj + 1 − Zij ∗L ∀i, j, i = j

(5)

  sik ≥ cjk − 2 + Yijk − Xik − Xjk ∗L ∀i, j, i = j, k ∈ AC i ∩ AC j

(6)

  sjk ≥ cik − 3 − Yijk − Xik − Xjk ∗L ∀i, j, i = j, k ∈ AC i ∩ AC j

(7)

Yijk + Yjik ≤ 1 ∀i, j, i = j, k ∈ AC i ∩ AC j

(8)

si ≥ 0 ∀i

(9)

ci ≥ 0 ∀i

(10)

Xik ∈ {0, 1} ∀i, k

(11)

Yijk ∈ {0, 1} ∀i, j, k, i = j

(12)

The objective function (1) aims to minimize FTD. Constraint (2) ensures that each task can only be executed on one aircraft. Constraints (3) and (4) restrict the task start time and completion time. Constraint (5) establishes the precedence logic between tasks. Constraint sets (6), (7) and (8) guarantee that no task will overlap on the same aircraft. Constraints (9) and (10) ensure that the start execution time and completion time of tasks are non-negative. Constraints (11) and (12) indicate the types of decision variables for Xik and Yijk .

3 Optimization Algorithm The task scheduling problem for flight tests is a typical NP-hard problem for which there are two main solution methods. The first type is the ‘exact method’ by which the optimal solution to a structured COP can be found. The exact method can guarantee to find the optimal solution for a finite-size instance of the problem in a finite time. However, the exact method may require exponentially increasing computational time, i.e., computational inefficiency with the increasing problem size. Therefore, the approximate method, which can obtain the solution to a problem in a short time, has attracted more attention from scholars in recent years. Approximate methods mainly include various heuristic algorithms and machine learning approaches. Typical algorithms in these three categories are described in detail below.

30

B. Tian et al.

3.1 Exact Methods Exact methods solve the problem by formulating mathematical models. Although this method can theoretically lead to the optimal solution of the problem, it is difficult to be widely used in practical environments as it is only suitable for solving small-scale simple problems and is inefficient in solving large-scale problems. Typical exact methods include the branch-and-bound method [8], the dynamic programming method [9], and the Lagrangian relaxation method [10]. For example, Tomazella et al. [11] provide a comprehensive review of branch-and-bound algorithms for solving flow shop scheduling problems. Deng et al. [12] proposed a practical dynamic planning-based optimization method for long-term maintenance inspection planning of a heterogeneous fleet. AsadiGangraj et al. [13] developed a Lagrangian relaxation algorithm to handle the hybrid flowshop scheduling problem to minimize the makespan. 3.2 Heuristic Algorithms The traditional heuristic is a search method for a specific problem based on intuitive or empirical constructs. In practical applications, the search is usually performed step by step to generate a solution for task execution based on certain rules. The first type of commonly used heuristics is the priority rules and related composite rules. The priority rules are usually based on information related to a specific indicator, such as task processing time, expected completion time, cost, slack time, etc. The related composite rules are often in the form of a combination of basic priority rules with their weights. Referring to the job-shop scheduling problem, Rajendran et al. [14] summarized the commonly used priority-based heuristic rules, such as latest finish time (LFT), latest start time (LST), shortest processing time (SPT), and longest processing time (LPT), etc. The second category of heuristic rules involves more complex considerations, such as load status, backup status, etc., and also includes some forms based on manual judgment rather than mathematics, based on insertion methods, based on shifting bottleneck procedures, etc. These rules in the second category are usually used together with the rules in the first category. Modern heuristics, i.e., metaheuristics, can usually be divided into two main categories, population strategy-based algorithms and trajectory strategy-based algorithms, according to whether they are computed using populations or not. Meta-heuristic algorithms based on population strategies, mainly inspired by biology, contain multiple parallel individuals in each generation. It usually includes two types of algorithms, one is the evolutionary algorithm, which simulates the natural selection mechanism of superiority, typical algorithms are genetic algorithm (GA) [15], genetic programming (GP) [16], differential evolution (DE) [17], etc.; the other is swarm intelligence algorithm, which simulates the synergy between individuals as the mechanism of learning, typical algorithms are particle swarm algorithm (PSO) [18], ant colony algorithm (ACO) [19], etc. In the scheduling literature, Hosseinabadi et al. [20] used GA to solve the open-shop scheduling problem (OSSP) and compared it with other existing algorithms. Zhang et al. [21] proposed a surrogate-assisted evolutionary multitask algorithm based on genetic programming to achieve knowledge sharing among different scheduling tasks to solve the dynamic flexible shop floor scheduling problem. Jana et al.

The Research on the Task Scheduling and Optimization Technology for Flight Tests

31

[22] developed a task-scheduling technique based on a particle swarm optimization algorithm in the cloud environment. Tran et al. [23] used the swarm intelligence algorithm ACO to solve the scheduling optimization of maintenance, repair, and overhaul (MRO) processes of remanufacturing with two objectives. Algorithms based on trajectory strategies have only one individual in each iteration, such as simulated annealing (SA) [24], tabu search [25], and various local search methods, etc. For example, Pang et al. [26] proposed a scatter-simulated annealing algorithm to solve the bi-objective scheduling problem for the wet station of semiconductor manufacturing. Gao et al. [27] proposed a method tabu search algorithm by swapping subsequences of jobs to generate neighbors for the distributed permutation flow shop scheduling problem. As described above, meta-heuristic algorithms have been shown to be effective in solving many COPs. However, as the metaheuristic algorithms are often designed for a specific type of optimization problem, the algorithms are poor in generalization for solving other optimization problems or even different test cases of the same problem. Additionally, the parameter settings of the metaheuristic algorithm also have a large impact on its performance. The above properties restrict the generality of meta-heuristic algorithms. Recently, hyper-heuristic technologies have emerged, which can be defined as a high-level automated search method that, given a specific problem instance and many low-level heuristics, can solve the problem by selecting and applying the appropriate low-level heuristic at each decision point [28]. In the literature, Burke et al. [29] provided a unified classification and definition of hyper-heuristic methods. Dimopoulos et al. [30] used genetic programming algorithms for heuristic rule generation to solve the onemachine scheduling problem in manufacturing. Garrido et al. [31] used the evolutionarybased hyper-heuristic method EH-DVRP to solve the dynamic vehicle routing problem. Although hyper-heuristics aim to increase the generality of search algorithms in solving various problems and instances, according to the current literature available, the majority of hyper-heuristics have only been tested on a single problem domain, and some have only been tested on a few specific problem domains. Hyper-heuristics’ generality across various problem domains still lacks specific criteria or unified norms to clarify. 3.3 Artificial Intelligence In recent years, with the development of artificial intelligence, there has been an increasing amount of research using machine learning to solve COPs. Machine learning can be classified according to the learning method: supervised learning, unsupervised learning, and reinforcement learning [32]. Supervised machine learning aims to build a model that makes predictions based on evidence in the presence of uncertainty. Supervised learning algorithms take a known set of input data and a known response to the data (output) and train the model to generate a reasonable prediction of the response to the new data [33]. Unsupervised learning discovers hidden patterns or intrinsic structures in the data. It is used to draw inferences from a dataset consisting of input data without labeled responses. Reinforcement learning is different from unsupervised and supervised machine learning in that reinforcement learning does not rely on static datasets, but operates in a dynamic environment and learns from the experience gathered. Data points or experiences are collected during

32

B. Tian et al.

training through trial-and-error interactions between the environment and the agent [34]. This aspect of reinforcement learning is important because it reduces the need for data collection, preprocessing, and labeling before training. Deep learning, or deep neural networks, is a special type of machine learning approach for supervised or unsupervised learning or integrated with reinforcement learning. Deep learning is a successful method for constructing parameter combinable functions in a high-dimensional space. As another important branch of deep learning, deep reinforcement learning (DRL) [35] is mainly used to make sequential decisions, i.e., to select actions based on the current state of the environment, and to continuously adjust its policy based on the reward feedback to achieve the given goals. The performance of deep reinforcement learning on problems such as AlphaGo Zero and Atari in recent years has shown its powerful learning and optimization decision-making capabilities. Combinatorial optimization, which is the optimal selection of decision variables in a discrete decision space, has naturally similar characteristics to the “action selection” of reinforcement learning, and the ‘offline training, online decision’ feature of DRL makes it possible to solve COPs in real-time. Therefore, it is a good choice to solve traditional COPs by using DRL methods. In the literature, a series of new methods have emerged in recent years to solve COPs using DRL methods, and have achieved good results. Compared with traditional algorithms for solving COPs, DRL-based have a series of advantages such as fast solution speed and strong generalization ability, and have become a hot topic recently. For example, Vinyals et al. [36] proposed the pointer network. On this basis, Ma et al. [37] proposed a Graph Pointer Network (GPNs) trained using reinforcement learning (RL) to solve the traveling salesman problem. Chen et al. [38] combined RL to tune the key parameters of a genetic algorithm when solving a flexible job shop scheduling problem. Etheve et al. [39] proposed an RL framework to learn the branching strategy of a branch and bound algorithm. Wang et al. [40] applied the Q-learning algorithm to the single-machine scheduling rule selection problem.

4 Numerical Experiments In this section, we evaluate the performance of the established MILP model and an improved GA (IGA). In the algorithm, a task sequencing vector and an aircraft assignment vector are the two components that form each chromosome. A left-shift-based decoding method is used to convert a chromosome into a schedule for the arranging of flight test tasks. The parameter settings for GA: population size is 50, crossover rate is 0.8, mutation rate is 0.2 and the maximum iteration is 100. The algorithms are coded in MATLAB R2020b and implemented on a computer configured with IntelCorei7 CPU with 2.60GHz frequency, and 16GB RAM. Table 2 illustrates the comparison results. The first three columns of the table indicate the instance label and the instance size of “Task number × aircraft number”. For each method, the best solution for FTD and the solving time Ts are presented. “-” indicates that a feasible solution is found within 600 s. Ts_best is the best solution obtained time for IGA. It can be observed that both the MILP model and the IGA method can obtain the optimal value for FTD on instances D1–D6. For the computing time, the solver time for solving the model is less than the total IGA iteration time. However, the optimal

The Research on the Task Scheduling and Optimization Technology for Flight Tests

33

Table 2. The comparison results Instance

Size

MILP

IGA

FTD

Ts

FTD

Ts

Ts_best

D1

40 × 3

126

1.070

126

20.680

0.245

D2

40 × 4

126

1.288

126

23.044

0.486

D3

40 × 5

126

1.904

126

24.122

0.244

D4

80 × 3

264

16.747

264

63.113

0.718

D5

80 × 4

264

10.652

264

68.220

0.716

D6

80 × 5

264

10.981

264

61.168

0.743

D7

120 × 3

341

600

332

157.533

44.439

D8

120 × 4

303

110.961

303

137.542

15.048

D9

120 × 5

303

84.804

303

110.782

1.218

D10

160 × 3

-

600

487

328.750

326.675

D11

160 × 4

394

600

386

184.860

163.793

D12

160 × 5

380

303.791

380

180.063

24.950

solution of IGA is obtained in less time than that of MILP solved time. It can be seen that the performance of the IGA algorithm is related to the setting of its parameters. For larger scale instances, the MILP model and IGA obtain the same solution while the IGA consumes less time. In other instances, such as D7, D10, and D11, the MILP model cannot obtain a more optimal value in the given time. Therefore, the IGA algorithm has better performance in terms of effectiveness and efficiency in large-scale problems. Although the MILP model is inefficient in solving large-scale problems, the MILP model is the basis for understanding the scheduling problem, and can find the optimal solution for small-scale problems and can be used as a reference standard for evaluating the quality of approximation methods. Therefore, the study of the MILP model is also meaningful.

5 Conclusion Flight test schedule directly impacts the flight test duration (FTD) and flight tests’ cost. A reasonable flight test task scheduling can reasonably mobilize flight test resources, reduce flight test risks, and improve flight test efficiency. This paper first describes the definition and classification of the task scheduling problem for flight tests. Then, the model formulations are introduced, and a MILP model is established for the singleobjective and static problem. Next, the solving methods are summarized and analyzed, including exact methods, heuristic algorithms, and artificial intelligence. Finally, the numerical experiments are conducted on the flight test task instances between the model and an improved genetic algorithm (IGA). The actual flight test activity is a very complex system engineering. Future research will look into the analysis and modeling of flight tests’ impact factors, the establishment

34

B. Tian et al.

of multiple objective models, the study of dynamic problems, and enhancement of the solving algorithms, etc.

References 1. Landi, A., Nicholson, M.: ARP4754A/ED-79A – guidelines for development of civil aircraft and systems – enhancements, novelties and key topics. SAE Int. J. Aerosp. 4, 871–879 (2011). https://doi.org/10.4271/2011-01-2564 2. Introduction to Flight Test Engineering: SciTech Book News. 21, 123 (1997) 3. Gregory, J.W., Liu, T.: Introduction to Flight Testing. John Wiley & Sons, Incorporated, Newark, Newark (2021) 4. Hewett, M.D., Tartt, D.M., Agarwal, A.: Automated Flight Test Management System. https:// www.nasa.gov/centers/dryden/pdf/88227main_H-1699.pdf (1991) 5. Flood, M.M.: The traveling-salesman problem. Operat. Res. 4(1), 61–75 (1956). https://doi. org/10.1287/opre.4.1.61 6. Zhang, J., Ding, G., Zou, Y., Qin, S., Jianlin, F.: Review of job shop scheduling research and its new perspectives under Industry 4.0. J. Intell. Manuf. 30(4), 1809–1830 (2019). https:// doi.org/10.1007/s10845-017-1350-2 7. Manasrah, A., Ali, H.: Workflow scheduling using hybrid ga-pso algorithm in cloud computing. Wirel. Commun. Mob. Comput. 2018, 1–16 (2018). https://doi.org/10.1155/2018/193 4784 8. Lawler, E.L., Wood, D.E.: Branch-and-bound methods: a survey. Oper Res. 14, 699–719 (1966). https://doi.org/10.1287/opre.14.4.699 9. Bellman, R.: The Theory of Dynamic Programming (1954) 10. Held, M., Karp, R.M.: The traveling-salesman problem and minimum spanning trees. Oper. Res. 18, 1138–1162 (1970). https://doi.org/10.1287/opre.18.6.1138 11. Tomazella, C.P., Nagano, M.S.: A comprehensive review of Branch-and-Bound algorithms: Guidelines and directions for further research on the flowshop scheduling problem. Expert Syst. Appl. 158, 113556 (2020). https://doi.org/10.1016/j.eswa.2020.113556 12. Deng, Q., Santos, B.F., Curran, R.: A practical dynamic programming based methodology for aircraft maintenance check scheduling optimization. Eur. J. Oper. Res. 281, 256–273 (2020). https://doi.org/10.1016/j.ejor.2019.08.025 13. Asadi-Gangraj, E.: Lagrangian relaxation approach to minimize makespan for hybrid flow shop scheduling problem with unrelated parallel machines. Scientia Iranica 25(6), 3765–3775 (2017). https://doi.org/10.24200/sci.2017.20018 14. Rajendran, C., Holthaus, O.: A comparative study of dispatching rules in dynamic flowshops and jobshops. Eur. J. Oper. Res. 116, 156–170 (1999). https://doi.org/10.1016/S0377-221 7(98)00023-X 15. Holland, J.H.: Adaption in natural and artificial systems, An Introductory Analysis with Application to Biology, Control and Artificial Intelligence (1975) 16. Banzhaf, W., Francone, F.D., Keller, R.E., Nordin, P.: Genetic Programming: An Introduction: on the Automatic Evolution of Computer Programs and its Applications. Morgan Kaufmann Publishers Inc. (1998) 17. Storn, R., Price, K.: Differential evolution – A simple and efficient heuristic for global optimization over continuous spaces. J. Global Optim. 11, 341–359 (1997). https://doi.org/10. 1023/A:1008202821328 18. Kennedy, J., Eberhart, R.: Particle swarm optimization. In: Proceedings of ICNN’95 – International Conference on Neural Networks, vol. 4, pp. 1942–1948 (1995). https://doi.org/10. 1109/ICNN.1995.488968.

The Research on the Task Scheduling and Optimization Technology for Flight Tests

35

19. Colorni, A.: Distributed optimization by ant colonies. In: Proceedings of the First European Conference on Artificial Life (1991) 20. Rahmani Hosseinabadi, A.A., Vahidi, J., Saemi, B., Sangaiah, A.K., Elhoseny, M.: Extended Genetic Algorithm for solving open-shop scheduling problem. Soft Comput. 23(13), 5099– 5116 (2019). https://doi.org/10.1007/s00500-018-3177-y 21. Zhang, F., Mei, Y., Nguyen, S., Zhang, M., Tan, K.C.: Surrogate-assisted evolutionary multitask genetic programming for dynamic flexible job shop scheduling. IEEE Trans. Evol. Comput. 25, 651–665 (2021). https://doi.org/10.1109/TEVC.2021.3065707 22. Jana, B., Chakraborty, M., Mandal, T.: A task scheduling technique based on particle swarm optimization algorithm in cloud environment. In: Ray, K., Sharma, T.K., Sanyog Rawat, R.K., Saini, A.B. (eds.) Soft Computing: Theories and Applications: Proceedings of SoCTA 2017, pp. 525–536. Springer Singapore, Singapore (2019). https://doi.org/10.1007/978-98113-0589-4_49 23. Tran, L.V., Huynh, B.H., Akhtar, H.: Ant colony optimization algorithm for maintenance, repair and overhaul scheduling optimization in the context of industrie 4.0. Appl. Sci. 9(22), 4815 (2019). https://doi.org/10.3390/app9224815 24. Steinbrunn, M., Moerkotte, G., Kemper, A.: Heuristic and randomized optimization for the join ordering problem. The VLDB J. 6, 191–208 (1997). https://doi.org/10.1007/s00778005 0040 25. Glover, F.: Future paths for integer programming and links to artificial intelligence. Comput. Oper. Res. 13, 533–549 (1986). https://doi.org/10.1016/0305-0548(86)90048-1 26. Pang, J., Zhou, H., Tsai, Y.-C., Chou, F.-D.: A scatter simulated annealing algorithm for the bi-objective scheduling problem for the wet station of semiconductor manufacturing. Comput. Ind. Eng. 123, 54–66 (2018). https://doi.org/10.1016/j.cie.2018.06.017 27. Gao, J., Chen, R., Deng, W.: An efficient tabu search algorithm for the distributed permutation flowshop scheduling problem. Int. J. Prod. Res. 51, 641–651 (2013). https://doi.org/10.1080/ 00207543.2011.644819 28. Pillay, N., Rong, Q.: Hyper-Heuristics: Theory and Applications. Springer International Publishing, Cham (2018) 29. Burke, E.K., Hyde, M.R., Kendall, G., Ochoa, G., Özcan, E., Woodward, J.R.: A classification of hyper-heuristic approaches: revisited. In: Gendreau, M., Potvin, J.-Y. (eds.) Handbook of Metaheuristics, pp. 453–477. Springer International Publishing, Cham (2019). https://doi. org/10.1007/978-3-319-91086-4_14 30. Dimopoulos, C., Zalzala, A.M.S.: Investigating the use of genetic programming for a classic one-machine scheduling problem. Adv. Eng. Softw. 32, 489–498 (2001). https://doi.org/10. 1016/S0965-9978(00)00109-5 31. Garrido, P., Riff, M.C.: DVRP: a hard dynamic combinatorial optimisation problem tackled by an evolutionary hyper-heuristic. J. Heuristics 16, 795–834 (2010). https://doi.org/10.1007/ s10732-010-9126-2 32. Jordan, M.I., Mitchell, T.M.: Machine learning: trends, perspectives, and prospects. Science 349(2015), 255–260 (1979) 33. Singh, A., Thakur, N., Sharma, : A review of supervised machine learning algorithms. In: 2016 3rd International Conference on Computing for Sustainable Global Development (INDIACom), pp. 1310–1315 (2016) 34. Kaelbling, L.P., Littman, M.L., Moore, A.W.: Reinforcement learning: a survey. J. Artif. Intell. Res. 4, 237–285 (1996). https://doi.org/10.1613/jair.301 35. Arulkumaran, K., Deisenroth, M.P., Brundage, M., Bharath, A.A.: Deep reinforcement learning: a brief survey. IEEE Signal Process. Mag. 34, 26–38 (2017). https://doi.org/10.1109/ MSP.2017.2743240

36

B. Tian et al.

36. Vinyals, O., Fortunato, M., Jaitly, N: Pointer Networks. In: Cortes, C., Lawrence, N., Lee, D., Sugiyama, M., Garnett, R. (eds.) Advamces Neural Information Process Systtem. Curran Associates, Inc.. https://proceedings.neurips.cc/paper/2015/file/29921001f2f04bd3baee84a1 2e98098f-Paper.pdf (2015) 37. Ma, Q., Ge, S., He, D., Thaker, D., Drori, I.: Combinatorial Optimization by Graph Pointer Networks and Hierarchical Reinforcement Learning (2019) 38. Chen, R., Yang, B., Li, S., Wang, S.: A self-learning genetic algorithm based on reinforcement learning for flexible job-shop scheduling problem. Comput. Indus. Eng. 149, 106778 (2020). https://doi.org/10.1016/j.cie.2020.106778 39. Etheve, M., Alès, Z., Bissuel, C., Juan, O., Kedad-Sidhoum, S.: Reinforcement learning for variable selection in a branch and bound algorithm. In: Hebrard, E., Musliu, N. (eds.) Integration of Constraint Programming, Artificial Intelligence, and Operations Research, pp. 176–185. Springer International Publishing, Cham (2020) 40. Wang, Y.-C., Usher, J.M.: Application of reinforcement learning for agent-based production scheduling. Eng. Appl. Artif. Intell. 18, 73–82 (2005). https://doi.org/10.1016/j.engappai. 2004.08.018

A Systematic Approach to Conducting FHA Jian Wang(B) AECC CAE, Shanghai, China [email protected]

Abstract. To develop a complex, safety-critical system, it is of great importance to identify the safety requirements at the earlier stage of system development. Functional Hazard Assessment technique is commonly used in order to identify top-level safety requirements based on the system functions. In this article, we present a systematic approach to conducting FHA starting from the list of system function, based on which the functional Failure Conditions are identified, then each Failure Condition is classified based on its Failure Effect. Different Failure Effects are categorised to different level of Severity, to which a safety goal is associated. By studying the chain from Failure Condition to Failure Effect, to Severity, and to the associated safety goal, the safety requirements for each Failure Condition can be determined at the end of Functional Hazard Assessment. Keywords: Complex System Safety Assessment · Functional Hazard Assessment · Failure Condition · Failure Effect · Severity

1 Introduction In the paradigm of complex system development, lack of sufficient safety feature usually leads to product redesign at a very high cost in terms of money, time, and business reputation. A bitter lesson learnt recently in the aviation industry is the redesign of the notorious Maneuvering Characteristics Augmentation System (MCAS) in the Boeing 737 MAX series aircraft. This made people realize again the importance of identifying safety requirements at the earlier stage of system development, and validating safety requirements in the course of system design evolution. In a top-down approach of system development, the capture and validation of safety requirements is in principle of iterative nature, mainly using Preliminary System Safety Assessment (PSSA) and Functional Hazard Assessment (FHA) techniques. Although the role of PSSA and FHA in the system development process has been effectively illustrated in SAE ARP4754A [6], the interaction between these two techniques has not been explained in detail. The guidelines and methods for conducting PSSA and FHA have been explained in SAE ARP4761 [5]. Noticeably, SAE ARP4761 is fairly old, and revision A (or SAE ARP4761A) was initiated since 2004 but is still in the state of Work In Progress (WIP) at the time of this article. According to SAE ARP4761 [5], which was published in 1996, PSSA is defined as ‘A systematic evaluation of a proposed system architecture and implementation based © The Author(s), under exclusive license to Springer Nature Singapore Pte Ltd. 2023 D. Krob et al. (Eds.): CSD&M 2023, LNEE 1085, pp. 37–46, 2023. https://doi.org/10.1007/978-981-99-6511-3_4

38

J. Wang

on the Functional Hazard Assessment and failure condition classification to determine safety requirements for all items’. With many years of industrial practice of safety work thereafter, this definition was slightly modified, as in SAE ARP4754A [6] published in 2010, to ‘A systematic evaluation of a proposed system architecture and its implementation, based on the Functional Hazard Assessment and Failure Condition classification, to determine safety requirements for systems and items’. Comparing these two definitions of PSSA, we noticed that, PSSA can be applied at both system and item levels of system design (i.e., at system, sub-system, all the way down to the item level) in order to determine the safety requirements at different levels. Yet another important message can be drawn from the aforementioned two definitions is that PSSA should be conducted based on the result of FHA. Indeed, PSSA has at least two purposes: 1. Confirming that the proposed system architecture and its implementation is safe; 2. Allocating safety requirements to the lower level specified in system architecture (system or item). While the result of FHA severs as part of the inputs to the work of PSSA, the definition of FHA, also given in SAE ARP4754A [6], ‘A systematic, comprehensive examination of functions to identify and classify Failure Conditions of those functions according to their severity.’, does not tell too much about the input information for conducting FHA, and what would be the outcome of FHA. Indeed, it is even improperly expressed in this definition that the classification of identified Failure Conditions is based on their severity. In practice, after being identified, Failure Conditions are first assessed in order to determine their Failure Effects, then different Failure Effects are further classified according to their Severity. Another important outcome of FHA would be the safety requirements determined for each identified Failure Condition. Although SAE ARP4761 [5] provided guidelines and methods for conducting FHA, it has become out-dated compared to the industrial experience accumulated after it was published. In the rest of this article, we would like to share our experience on how to conduct FHA, starting from examining the necessary input information, identifying Failure Conditions (FC), assessing Failure Effects (FE) for each identified FC, classifying the Severity of each FE, and last but not least, determining the safety requirements for each identified FC. FHA can be conducted at any level of the system architecture of any system, regardless if it is at aircraft, car, rocket, nuclear reactor, chemical process, aircraft engine, braking system, control system or at an item level. In order to keep the description as general as possible, in the rest of this article, we call the system under the study of FHA as the Subject System (SS).

2 Review of Input Data of FHA Given the background and context of FHA in Sect. 1, now it’s time to check if the necessary information is available in order to start FHA. As given in its definition, FHA is ‘a systematic, comprehensive examination of functions …’, the starting point of FHA is usually a list of expected functions prescribed to the Subject System (SS) by the system development process at a higher level. Depending on the location of SS in the

A Systematic Approach to Conducting FHA

39

overall system architecture, the prescribed functions can come from captured customer requirements, or as a result of functional analysis at the same level as that of SS. Some other information, such as the system operational environment/context, overall system architecture, etc. would also be available at this stage, and would be useful when identifying the Failure Conditions and assessing its Failure Effects as described in Sect. 3 and 4. In short, the following are the list of information/documentation necessary to conduct FHA: 1. List of Functions with description and inter-relationship between Functions limited to the abstraction level of SS; 2. Operating environment/context of SS, e.g., the flight phase definition in case that SS represents an aircraft; 3. System architecture description not necessarily exhausted to details but sufficient to the level of SS; Taking the Braking System of a vehicle as an example of Subject System, which serves to slow down or stop the vehicle by converting the kinetic energy of the vehicle into heat energy through friction. At the system architecture design stage, a Braking System has been identified as one of the sub-systems of the vehicle, and its functions have been determined as: 1. Apply Braking Force The system should be able to apply the necessary braking force required to slow down or stop the vehicle. 2. .Maintain Braking Force The system should maintain the braking force even under different driving conditions and situations, such as uneven road surfaces, emergency stops, etc. 3. Distribute Braking Force. The system should distribute the braking force evenly among all the wheels to ensure stable and safe braking. It is very important to keep in mind, that at the stage of specifying the vehicle architecture down to the level of Braking System, together with the other systems like the Engine System, Transmission System, Electrical System, Suspension System, Steering System and Fuel System at the same level, it is not necessary to consider how to realise (or implement) the functions of Braking System, with even more detailed design at lowerlevel, such as Anti-lock Braking System (ABS), Parking Brake, Hydraulic or Pneumatic System, Brake Discs/Drums, Brake Pads/Shoes, Brake Calipers/Wheel Cylinders, or Brake Lines and Hoses, etc. Another good example is the Engine Electronic Control System (EECS) for an aircraft engine as a Subject System. As the most complex system of an aircraft engine, in order to keep the engine performance within a safe and efficient margin, the functions of the EECS usually include: 1. Fuel Control EECS modulates the fuel flow into the Combustion Chamber of an engine; 2. Engine Geometry Control

40

3.

4.

5.

6.

7. 8.

J. Wang

For jet engine featured with variable-geometry structure, EECS adjusts the vanes angle at different engine stages according to the engine operating conditions; Heat Management EECS monitors the fuel and oil temperature and pressure, and take actions (applying cooling air, changing the fluid circulation path, etc.) accordingly; Engine Health Monitoring and Annunciation EECS monitors the engine conditions and operating parameters, detects any abnormality or malfunction, applies any necessary mitigation actions, annunciates the engine states to the flight crew if necessary; Thrust/Power Management EECS determines the Thrust/Power level and control mode of the engine based on aircraft demand and current engine operating condition; Engine Protection EECS may determine any emergency threats (over-speed, over-temperature, extreme vibration, inclement weather condition, volcanic ash, single event effect, etc.) and take proper action in order to protect engine from potential damage; Engine Start-up and shut-down EECS manages the engine start-up and shut-down procedures; Bleed Regulation EECS regulate the engine bleeds from different stages for the purpose of cooling, anti-icing, performance and customer service; Again, at this stage of engine architecture design, there is no need to consider how to realise (or implement) the functions of EECS with different types of sensors, actuators, electronic controller or software.

3 Identification of Functional Failure Conditions (FC) The input data as described in Sect. 2 should suffice to start the work of FHA beginning with the identification of Failure Conditions (FC). SAE ARP4754A [6] agrees with the definition of Failure Conditions from AMC 25.1309 in EASA CS-25 [3] as: ‘A condition having an effect on the aeroplane and/or its occupants, either direct or consequential, which is caused or contributed to by one or more failures or errors, considering flight phase and relevant adverse operational or environmental conditions, or external events.’. Obviously, this definition of FC is limited to the aircraft (Aeroplane as specified by EASA CS-25 [3], or Transport Category Airplanes as specified by 14 CFR Part 25 from FAA)1 . As we have determined in Sect. 1 to apply FHA at any given Subject System (SS), a generalisation to this definition is necessary. For this purpose, we simply consider Failure Condition as a state of an SS, in which the SS cannot perform its intended functions. So far, we are not interested in ‘what is the cause of the Failure Condition’, or ‘how the function is affected’. One way to identify the Failure Conditions is to start with the functions of the SS by which it is expected to perform. For that an examination to List of Functions as described in Sect. 2 would be a good practice. In this context, any type of malfunction, including 1 Noticeably, the Failure Conditions defined in EASA AMC 25.1309 is not dedicated for the

purpose of conducting FHA.

A Systematic Approach to Conducting FHA

41

loss of function, can be considered as an FC. In general, different type of malfunction can be identified by considering different aspects of a function, such as whether it is about the. 1. Magnitude a. too high, strong, long? b. too low, weak, short? c. oscillating? d. drifting? 2. Timing a. too early? b. too late? c. less frequent? d. or too often? 3. Grade a. totally lost? b. partially lost? 4. Duration a. last too long? b. last too short? A Failure Condition can also be identified as a result of multiple dysfunctions while the mechanism is not yet understood at the time of assessment, e.g., set on fire, become over-temperature, etc. However, the phenomenon of such Failure Condition would be observable, or measurable. We shall talk about such kind of Failure Condition later in Sect. 4.

4 Assess Failure Effect of Functional FC Unlike the common guidelines as presented in SAE ARP4761 [5], we tend to emphasise the difference between Failure Conditions and their Failure Effect (FE): an FC is simply a situation in which the Subject System cannot perform its indented function; however, the Failure Effect is considered as the consequence at the SS level or at the level above the SS in the system architecture, given the condition when SS remains in such situation. The Failure Effect of an FC is usually measurable, or observable, and should be assessed at least to the same level of the Subject System (SS), but preferably be assessed at levels higher than that of SS, provided sufficient evidence/assumption are available in order to support such assessment. This is mainly due to the fact that at higher level, the consequence of the FC would be easier to observe, and in most cases, more concrete regulatory restrictions or constraints are imposed by different authorities or institutes, and will therefore facilitate the determination of safety requirements of FC, which is discussed in Sect. 6 of this article. For example, given the type certification regulation available at the aircraft-level, such as CCAR Part 25, FAA 14 CFR Part 25, and EASA CS-25, the Failure Effect of an SS as aircraft would be sufficiently assessed at the same level as at aircraft-level; while given the type certification regulation only available at the engine-level, such as CCAR Part 33, FAA 14 CFR Part 33, and EASA CS-E, the Failure

42

J. Wang

Effect of an SS as Engine Electronic Control System (EECS) should not be limited at EECS-level, but preferably be extended up to the engine-level. Given a phrase of failure description, sometimes it may not be easy to tell if the failure description is an FC or an FE to a Subject System. This is mainly due to the fact that an FE of a Subject System would become the Failure Condition of another SS at higher level. In this situation, the assessor is advised to keep firmly at the level of the Subject System, and try to identify the causal relationship between the failure description and the expected function of the SS. If the described failure can be directly related to an expected function of the SS, then this failure description is an FC to the SS; or, If the described failure can be related to the errors of lower-level function/components of the SS, then the failure description is an FE to the SS. For example, consider Aircraft Engine as an SS, a failure description of ‘Loss of Thrust Control’ is directly related to the function of ‘generating thrust according to received command’, which is one of the functions of an Aircraft Engine, therefore ‘Loss of Thrust Control’ is an FC to the Aircraft Engine; on the other hand, consider Engine Electronic Control System (EECS) as an SS, the same failure description of ‘Loss of Thrust Control’ is caused by different errors in lower-level components of EECS, therefore ‘Loss of Thrust Control’ is an FE of EECS. For a set of FCs, although it is possible to assess the Failure Effects for different FC at different levels in the system architecture higher or the same level as that of SS, it should be kept in mind that in principle, all the Failure Effects should be assessed at the same level. This is due to the fact that the Failure Effects will be categorised based on their Severity as described in Sect. 5 at a specific level. If a Failure Condition is identified as a result of multiple dysfunctions in SS, as described in Sect. 3, they are usually described based on its effect to the SS. In this case, such Failure Condition can also be considered as the Failure Effect at the same level of SS in the system architecture. Unless we assess the Failure Effect at a higher level for the SS, it is not necessary to assess such FC for its FE any further, since in this case, such FC would be identical to its FE.

5 Categorisation of Failure Effects Based on Severity We define Severity as a set of categories inversely related to the Failure Effects. It is worthwhile to emphasise that the relationship between Severity and Failure Effect are inverse relation since this relationship are not causal, and are merely subjective. For example, AC 25.1309-1A [1] from FAA proposed Severity categories of ‘Minor’, ‘Major’, and ‘Catastrophic’ at aircraft-level such that: 1. Minor: Not significantly reduce airplane safety, may involve crew actions that are well within their capabilities; 2. Major: large reduction in safety margins, or reduction in functional capabilities, or higher workload on crew, or adverse effects on occupants; 3. Catastrophic: prevent continued safe flight and landing.

A Systematic Approach to Conducting FHA

43

Note that, the Severity categories defined here setup a relationship to a set of Failure Effects at the aircraft-level. While CS-E 510 [2] from EASA proposed Severity categories of ‘Minor’, ‘Major’, and ‘Hazardous’ at aircraft engine level such as: 1. Minor: partial or complete loss of thrust or power from the Engine; 2. Major: any effect between ‘Minor’ and ‘Hazardous’; 3. Hazardous: in case of the following effects: a. Non-containment of high-energy debris; b. Concentration of toxic products in the Engine bleed air for the cabin sufficient to incapacitate crew or passengers; c. Significant thrust in the opposite direction to that commanded by the pilot; d. Uncontrolled fire; e. Failure of the Engine mount system leading to inadvertent Engine separation; f. Release of the propeller by the Engine, if applicable; g. Complete inability to shut the Engine down. Obviously, the Severity categories defined here setup a relationship to a set of Failure Effects at the aircraft engine level. Apart from the above Severity categories proposed in the civil aviation industry, other industrial area may propose Severity categories based on their own safety practice. For example, in automotive industry, the Severity categories are proposed in ‘ISO 26262, part 3, appendix B, classification of the severity factor’, according to the book of ‘Functional Safety for Road Vehicles – New Challenges and Solutions for E-mobility and Automated Driving’ [4] as: 1. light and moderate injuries (S1) 2. severe/serious injuries possibly life-threatening, survival is likely (S2) 3. life-threatening injuries (survival uncertain) or deadly injuries (S3) Again, the Severity categories defined here setup a relationship to a set of Failure Effects at the road vehicle level. The reason of specifying different Severity categories is that the safety practice of different industries tends to setup a safety goal in terms of probability, qualitatively and/or quantitatively, based on a common degree of Severity which can be related to the Failure Effect. In this way, individual system developer can describe the Failure Effect to their own product at their own ease. Figure 1 is the safety goals as an example in civil aviation industry according to different FAA regulations or EASA specifications for aircraft and aircraft engines.

44

J. Wang

Fig. 1. Safety Goals Depending on Severity in terms of Probability in Aviation Industry

6 Determine Safety Goal for Each Failure Effect Having explained the relations between Functions and functional Failure Conditions, between functional Failure Conditions and Failure Effects, and between Failure Effects and Severity, now we are ready to determine the safety requirement for each identified Failure Condition, which is the major purpose of FHA. Next, we will explain this procedure using a generic example. Table 1 represents the identified Failure Conditions (FCs) related to the Function of our Subject System (SS), and for Failure Condition its associated Failure Effect to the level of SS or higher in the system architecture. Remember, the Failure Effect should remain to the same level for all Failure Conditions, as we have emphasised in Sect. 4. Table 1. Identified Functional Failure Conditions and Effects Function

Failure Condition

Failure Effect@Level

F1

FC1-1

E1

FC1-2

E2

F2

FC2-1

E3

FC2-2

E1

F3

FC3-1

E3

FC3-2

E1

FC4-1

E2

FC4-2

E1

F4

A Systematic Approach to Conducting FHA

45

Re-organise the Failure Conditions in Table 1 based on their Failure Effect at a given level and associated Severity would result in Table 2, in which the contribution of each Failure Condition to associated safety goals are clearly concluded. Table 2. Functional Failure Conditions and Safety Goals Failure Condition

Failure Effect@Level

Safety Goal@Severity

FC1-1

E1