Modern Spacecraft Guidance, Navigation, and Control PDF

MODERN SPACECRAFT GUIDANCE, NAVIGATION, AND CONTROL This page intentionally left blank MODERN SPACECRAFT GUIDANCE, NAVIGATION, AND CONTROL FROM SYSTEM MODELING TO AI AND INNOVATIVE APPLICATIONS Edited by VINCENZO PESCE Airbus D&S, Advanced Studies Department, Toulouse, France ANDREA COLAGROSSI Politecnico di Milano, Aerospace Science and Technology Department, Milan, Italy STEFANO SILVESTRINI Politecnico di Milano, Aerospace Science and Technology Department, Milan, Italy Elsevier Radarweg 29, PO Box 211, 1000 AE Amsterdam, Netherlands The Boulevard, Langford Lane, Kidlington, Oxford OX5 1GB, United Kingdom 50 Hampshire Street, 5th Floor, Cambridge, MA 02139, United States Copyright Ó 2023 Elsevier Inc. All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or any information storage and retrieval system, without permission in writing from the publisher. Details on how to seek permission, further information about the Publisher’s permissions policies and our arrangements with organizations such as the Copyright Clearance Center and the Copyright Licensing Agency, can be found at our website: www.elsevier.com/permissions. This book and the individual contributions contained in it are protected under copyright by the Publisher (other than as may be noted herein). Notices Knowledge and best practice in this ﬁeld are constantly changing. As new research and experience broaden our understanding, changes in research methods, professional practices, or medical treatment may become necessary. Practitioners and researchers must always rely on their own experience and knowledge in evaluating and using any information, methods, compounds, or experiments described herein. In using such information or methods they should be mindful of their own safety and the safety of others, including parties for whom they have a professional responsibility. To the fullest extent of the law, neither the Publisher nor the authors, contributors, or editors, assume any liability for any injury and/or damage to persons or property as a matter of products liability, negligence or otherwise, or from any use or operation of any methods, products, instructions, or ideas contained in the material herein. ISBN: 978-0-323-90916-7 For information on all Elsevier publications visit our website at https://www.elsevier.com/books-and-journals Publisher: Matthew Deans Acquisitions Editor: Chiara Giglio Editorial Project Manager: Sara Greco Production Project Manager: Surya Narayanan Jayachandran Cover Designer: Christian J. Bilbow Typeset by TNQ Technologies Contents List of contributors xi Biography xiii PART 0 Introduction 1. Introduction 3 Vincenzo Pesce, Andrea Colagrossi and Stefano Silvestrini Modern spacecraft GNC: what, why, how, for whom? 3 A brief historical review of classical spacecraft GNC 10 GNC terminology 13 GNC architecture: from requirements to preliminary design 15 Notation rules 38 References 42 PART 1 Fundamental GNC tools 2. Reference systems and planetary models 45 Andrea Colagrossi, Stefano Silvestrini and Vincenzo Pesce Earth and planetary models 46 Coordinate reference systems 53 Coordinate transformations 63 Time 69 What is relevant for GNC? 73 References 75 3. The space environment 77 Andrea Capannolo, Emanuele Paolini, Andrea Colagrossi, Vincenzo Pesce and Stefano Silvestrini Perturbation sources 78 External perturbations 79 External perturbations modeling guidelines 97 Internal perturbations 100 Internal perturbations modeling guidelines 123 What is relevant for GNC? 124 References 126 v j vi Contents 4. Orbital dynamics 131 Andrea Capannolo, Stefano Silvestrini, Andrea Colagrossi and Vincenzo Pesce Two-body problem 132 Three-body problem 161 Irregular solar system bodies 170 Relative orbital dynamics 174 References 204 5. Attitude dynamics 207 Aureliano Rivolta, Andrea Colagrossi, Vincenzo Pesce and Stefano Silvestrini Attitude kinematics 208 Attitude dynamics 227 Three-body problem attitude dynamics 248 Relative attitude dynamics 249 Multibody spacecraft dynamics 250 References 252 6. Sensors 253 Andrea Colagrossi, Vincenzo Pesce, Stefano Silvestrini, David Gonzalez-Arjona, Pablo Hermosin and Matteo Battilana Sensor modeling for GNC 254 Sensor faults 275 Orbit sensors 276 Attitude sensors 286 Inertial sensors 306 Electro-optical sensors 322 Altimeters 330 References 334 7. Actuators 337 Andrea Colagrossi, Lisa Whittle, Vincenzo Pesce, Stefano Silvestrini and Matteo Battilana Actuator modeling for GNC 338 Thrusters 344 Reaction wheels 354 Control moment gyros 366 Magnetorquers 369 References 375 Contents vii PART 2 Spacecraft GNC 8. Guidance 381 Thomas Peters, Stefano Silvestrini, Andrea Colagrossi and Vincenzo Pesce What is guidance? 381 On-board versus ground-based guidance 382 Guidance applications 385 Guidance implementation best practices 438 References 438 9. Navigation 441 Vincenzo Pesce, Pablo Hermosin, Aureliano Rivolta, Shyam Bhaskaran, Stefano Silvestrini and Andrea Colagrossi What is navigation? 441 On-board versus ground-based navigation 443 Sequential ﬁlters 445 Batch estimation 461 Absolute orbit navigation 470 Absolute attitude navigation 488 Relative navigation 504 Image processing techniques 507 Navigation budgets 528 Navigation implementation best practices 533 References 540 10. Control 543 Francesco Cavenago, Aureliano Rivolta, Emanuele Paolini, Francesco Sanfedino, Andrea Colagrossi, Stefano Silvestrini and Vincenzo Pesce What is control? 543 Control design 545 Review of control methods 592 Control budgets 618 Control implementation best practices 626 References 629 11. FDIR development approaches in space systems 631 Massimo Tipaldi, Stefano Silvestrini, Vincenzo Pesce and Andrea Colagrossi FDIR in space missions, terms, and deﬁnitions 633 Current FDIR system development process and industrial practices 637 viii Contents FDIR system hierarchical architecture and operational concepts 639 FDIR system implementation in European Space missions 641 FDIR system veriﬁcation and validation approach 642 FDIR concept and functional architecture in GNC applications: a short overview 642 References 645 12. GNC veriﬁcation and validation 647 Francesco Pace, Emanuele Paolini, Francesco Sanfedino, Daniel Alazard, Andrea Colagrossi, Vincenzo Pesce and Stefano Silvestrini Why it is important? 648 Statistical methods 652 MIL test 656 SIL/PIL test 667 HIL test 677 In-orbit test 682 References 683 13. On-board implementation 685 David Gonzalez-Arjona, Vincenzo Pesce, Andrea Colagrossi and Stefano Silvestrini Spacecraft avionics 686 On-board processing avionics 694 On-board implementation alternatives 700 On-board implementation and veriﬁcation 705 References 711 PART 3 AI and modern applications 14. Applicative GNC cases and examples 715 Stefano Silvestrini, Andrea Colagrossi, Emanuele Paolini, Aureliano Rivolta, Andrea Capannolo, Vincenzo Pesce, Shyam Bhaskaran, Francesco Sanfedino and Daniel Alazard AOCS design 717 Orbital control system 730 Attitude control system 742 Relative GNC 775 On-board sensor processing 791 Contents ix Irregular solar system bodies ﬂy around 803 GNC for planetary landing 806 References 814 15. Modern Spacecraft GNC 819 Stefano Silvestrini, Lorenzo Pasqualetto Cassinis, Robert Hinz, David Gonzalez-Arjona, Massimo Tipaldi, Pierluigi Visconti, Filippo Corradino, Vincenzo Pesce and Andrea Colagrossi AI in spacedIntroduction 821 Artiﬁcial intelligence and navigation 867 Validation of AI-based systems 883 Reinforcement learning 890 AI use cases 906 AI on-board processors 923 Innovative techniques for highly autonomous FDIR in GNC applications 925 Small satellites/CubeSats 938 References 971 Further reading 981 16. Mathematical and geometrical rules 983 Andrea Capannolo, Aureliano Rivolta, Andrea Colagrossi, Vincenzo Pesce and Stefano Silvestrini Matrix algebra 983 Vector identities 991 Quaternion algebra 994 Basics of statistics 1000 ECI-ECEF transformation 1002 References 1006 17. Dynamical systems theory 1007 Francesco Cavenago, Andrea Colagrossi, Stefano Silvestrini and Vincenzo Pesce State-space models 1007 Discrete-time systems 1009 Transfer functions 1011 References 1015 x Contents 18. Autocoding best practices 1017 Francesco Pace, Vincenzo Pesce, Andrea Colagrossi and Stefano Silvestrini List of main architectural and implementation rules 1017 Reference 1026 Index 1027 List of contributors Daniel Alazard ISAE-SUPAERO, Toulouse, France Matteo Battilana OHB Italia S.p.A., Milan, Italy Shyam Bhaskaran NASA Jet Propulsion Laboratory, Pasadena, CA, United States Andrea Capannolo Politecnico di Milano, Milan, Italy Lorenzo Pasqualetto Cassinis TU Delft, Delft, the Netherlands Francesco Cavenago Leonardo, Milan, Italy Andrea Colagrossi Politecnico di Milano, Milan, Italy; Airbus D&S Advanced Studies, Toulouse, France Filippo Corradino Tyvak International, Turin, Italy David Gonzalez-Arjona GMV Aerospace & Defence, Madrid, Spain Pablo Hermosin Deimos Space, Madrid, Spain Robert Hinz Deimos Space, Madrid, Spain Francesco Pace GMV Aerospace & Defence, Madrid, Spain Emanuele Paolini D-Orbit, Fino Mornasco, Italy Vincenzo Pesce Airbus D&S Advanced Studies, Toulouse, France Thomas Peters GMV Aerospace & Defence, Madrid, Spain Aureliano Rivolta D-Orbit, Fino Mornasco, Italy Francesco Sanfedino ISAE-SUPAERO, Toulouse, France xi j xii List of contributors Stefano Silvestrini Politecnico di Milano, Milan, Italy Massimo Tipaldi University of Sannio, Benevento, Italy Pierluigi Visconti Tyvak International, Turin, Italy Lisa Whittle Asteroid Exploration, Leiden, the Netherlands Biography Dr. Vincenzo Pesce is a guidance, navigation, and control (GNC) engineer at Airbus D&S Advanced Studies Department in Toulouse. Prior to joining Airbus, he worked for GMV, Spain. He holds a PhD in Aerospace Engineering from Politecnico di Milano with a thesis titled “Autonomous Navigation for Close Proximity Operations around Uncooperative Space Objects.” During his studies, he spent a research period at NASAdJet Propulsion Laboratory (2017) and at the University of Florida (2015). He is author or coauthor of about 30 scientiﬁc publications on GNC, autono- mous navigation, small-body exploration, and microgravity experiments in international journals and conference proceedings. He received the prestigious Leonardo Committee Graduation Award and the Guido Horn D’Arturo Award for his research on vision-based autonomous navigation. He has been involved in several international projects in collaboration with European companies and agencies. Recently, he has been working on the development of GNC algorithms for the Mars Sample Return mission and for the ESA’s European Large Logistics Lander project. His cur- rent research interests include autonomous GNC for proximity operations, rendezvous and landing, vision-based navigation, and GNC innovative methods. Dr. Andrea Colagrossi is an assistant professor of ﬂight mechanics at the Aerospace Science and Technology Department of Politecnico di Milano. He holds a PhD in Aerospace Engineering with a thesis on “Abso- lute and Relative 6DOF Dynamics, Guidance and Control for Large Space Structures in Cislunar Environment.” He earned his MSc degree in Space Engineering in 2015 from Politecnico di Milano, with a double degree from Politecnico di Torino. In 2012, he obtained his BSc degree in Aero- space Engineering at Politecnico di Torino. He was a visiting researcher at Deimos Space (Spain) and Purdue University (Indiana, USA). He has been involved in several national and international-funded projects, collab- orating with Italian and European companies, institutions, and agencies, working on development studies about GNC for modern applications, such as nanosat constellations for astrophysical observations, rendezvous in cislunar environment, and proximity operations for active debris removal. He is author and coauthor of about 30 scientiﬁc publications in international journals and conference proceedings on GNC, small space systems, and non-Keplerian dynamics. His main research interests are spacecraft GNC xiii j xiv Biography and system engineering for advanced small satellite applications, with a focus on effective GNC implementation with limited hardware resources, inno- vative GNC techniques, and autonomous failure and contingency modes management. Dr. Stefano Silvestrini is a postdoctoral researcher at the Aerospace Science and Technology Department of Politecnico di Milano. He obtained his PhD cum laude with a thesis titled “AI-augmented Guidance, Naviga- tion and Control for Proximity Operations of Distributed Systems.” He earned his MSc degree in Aerospace Engineering in 2017 from TU Delft. In 2016, he worked as a trainee for Airbus D&S in Munich. In 2015, he earned his BSc degree in Aerospace Engineering at the Universita degli Studi di Padova. During his BSc, he spent a six-month research period at the Col- lege of Aerospace Engineering of Boston University under awarded schol- arship. He has been involved in national and EU/ESA-funded projects for developing nanosat constellation for science observation, mission analysis, and system design for fractionated space architecture and artiﬁcial intelli- gence (AI) for spacecraft GNC. He has worked as a teaching assistant for several courses throughout his MSc and PhD career. His research interests include the development of AI algorithms for autonomous GNC in distrib- uted space systems and proximity operations, particularly tailored for embedded applications in small platforms. PART 0 Introduction 1 j This page intentionally left blank CHAPTER ONE Introduction Vincenzo Pesce1, Andrea Colagrossi2, Stefano Silvestrini2 1 Airbus D&S Advanced Studies, Toulouse, France 2 Politecnico di Milano, Milan, Italy Modern spacecraft GNC: what, why, how, for whom? Ever since the beginning of human existence, humans had to rely on basic tools, or simply on their intuition, to “guide” themselves throughout their habitat, developing instrument to “determine their location” and to “act” accordingly. The concept of Guidance, Navigation, and Control (GNC), even if in a different fashion, was familiar to the ﬁrst nomadic tribes and to the following pioneers of human exploration. Still, it is true that everyone approached the GNC problem in his own life, by simply going outside home and walking. Spaceﬂight has been one of the most revolutionary shades of human exploration, allowing men and automated vehicles to escape Earth’s gravity, turning imagination and wonder into reality. The technology of satellites and space vehicles has rapidly evolved since the ﬁrst signal received from the Sputnik 1 (Спутник 1) or the ﬁrst awe-inspiring images from the Moon surface, becoming now capable to land man-made objects on planets, comets, and asteroids, or to deploy constellations of orbiting bodies, or to make two spacecraft encounter while traveling thousands of kilometers per second. In performing all these activities, one of the original problems of human- ity came back under a new perspective: spacecraft GNC. Even in space, one needs to know the path, the current location, and the steps to stay on the right track. In these regards, spacecraft GNC has followed a quick techno- logical evolution, drawing inspiration from the ﬁrst Earth-based methods, such as sextants, chronometers, and landmarks, to rapidly evolve acquiring the peculiarities of the space environment. Then, with the arising of power- ful computers and advanced techniques, this branch of spacecraft technology made giant leaps toward autonomy and high performances. Nowadays, it is at the dawn of a new era, with artiﬁcially intelligent machines starting to help space explorers to travel across the solar system. Modern Spacecraft Guidance, Navigation, and Control © 2023 Elsevier Inc. j ISBN: 978-0-323-90916-7 https://doi.org/10.1016/B978-0-323-90916-7.00001-9 All rights reserved. 3 4 Vincenzo Pesce et al. This book aims at presenting an updated and comprehensive set of the- ory and applications about spacecraft GNC, from fundamentals to advanced concepts, including modern artiﬁcial intelligence (AI)-based architectures, with focus on software and hardware practical applications. In fact, one of the main purposes of this book is to discuss updated GNC design and vali- dation processes, from requirements to ﬁnal system implementation. This book is focused on delivering a coherent path to design a spacecraft GNC system, starting from theory and digging the critical steps toward implemen- tation. In other words, the book is intended to provide the necessary theory, omitting redundant derivations, already present in literature, from the spe- ciﬁc perspective of spacecraft systems. The topics discussed in the book are typically found scattered in a vast pool of literature; or they are limited to academic theoretical manuals, which have been published quite few years ago; or they are available from docu- mentation and technical notes, retrieved from international standards, which are not easy to be understood maintaining a general overlook on the whole problem. Moreover, GNC is typically regarded as the convergence of the three individual entities: Guidance, Navigation, and Control. This is partially valid; nevertheless, a holistic approach in the design of the system is lacking in book-type literature. The book starts from a revision of the basic tools and theoretical back- ground required to understand how a spacecraft moves in space and what are the elements a GNC system requires to be operative. Then, the main GNC blocks are introduced, describing their role within the overall ensemble, and explaining some theoretical foundations to understand the methods and technologies of spacecraft GNC. The discussion begins from the basic knowledge needed to understand the GNC system design process, and it is integrated with the steps driving from the requirements to the sys- tem implementation and veriﬁcation. Finally, spacecraft GNC applications and examples are discussed, together with a broad survey on modern tech- niques, methods, and scenario, including an extensive chapter on the role of AI in modern spacecraft GNC. This book does not want to provide an in-depth theoretical description of GNC foundations, but it offers a unique perspective on design and veri- ﬁcation processes, practical applications, and novel, cutting-edge, techniques. A unique text to understand the fundamentals of modern spacecraft GNC design, from theory to applications, which can guide both students, young professionals, and experts, is currently missing. The practical and Introduction 5 applicative focus of the book makes is appealing to junior and graduate aero- space engineers. Moreover, the discussion on modern and advance tech- niques should make it a reference updated handbook. In fact, spacecraft system engineers and attitude and orbit control system (AOCS)/GNC spe- cialists may want to use it to be updated on the latest promising advancements. In summary, the book may address different categories of readers: devel- opers, researchers, young professionals, Ph.D. students, designers in the ﬁeld of spacecraft GNC; AOCS and system engineers; Assembly Integration and Veriﬁcation/ Assembly Integration and Test (AIV/AIT) technicians; profes- sionals in the ﬁeld of estimation and control sciences who want to approach the space sector; experts who are looking for an updated discussion on mod- ern problems and applications. Book content Following this introductory part, the book has three main parts plus an ap- pendix section. The ﬁrst Part 1 e Basic Tools offers an overview of the main theoretical and fundamental concepts supporting spacecraft GNC. In particular, the used reference systems and planetary models are detailed along with the most important elements of the space environment. An overview of the main orbital and attitude dynamical models is provided. Subsequently, sensors and actuators are described, with particular focus on common GNC-related issues and on the most relevant modeling principles. With more details: Reference Systems and Planetary Models contains the models to describe planetary geometry, with a brief introduction to position representation methods; the main coordinate reference systems; the methods to transform the coordinates from one reference system to another one; the primary time conventions and scales, including the concept of Julian dates; a ﬁnal section summarizing the most relevant aspects for the GNC system. The Space Environment chapter describes the main perturbation sources inﬂuencing the spacecraft dynamics, dividing between external perturba- tions (i.e., nonspherical gravitational, magnetic ﬁeld, atmospheric drag, solar radiation pressure, and third-body) and internal ones (i.e., ﬂexibility and sloshing, electromagnetic disturbances, internal vibrations, thermal snap, parasitic forces and torques due to thruster ﬁring and plume impingement); the main guidelines to model the perturbation contributions; the concepts relating external and internal perturbations with the GNC design. 6 Vincenzo Pesce et al. The chapter on Orbital Dynamics introduces the two-body problem and the three-body problem, with the most useful elements for a GNC engi- neer; the gravitational environment around irregular solar system bodies; the relative orbital dynamics. The Attitude Dynamics chapter presents the fundamental rules and methods to deal with attitude kinematics; attitude dynamics, including a dis- cussion on the inertia properties of the spacecraft and on the main equations to deal with signiﬁcant attitude motions; relative attitude dynamics; multi- body spacecraft dynamics. The chapter about Sensors discusses the main sensor modeling concepts for spacecraft GNC, including some elements of metrology, and the basic principles about statistics and random variables; orbit sensors; attitude sen- sors, inertial sensors; electro-optical sensors; altimeters. The chapter about Actuators discusses the main actuator modeling prin- ciples for spacecraft GNC; thrusters; reaction wheels; control moment gyros; magnetorquers. Part 2 e Spacecraft GNC represents the core of the book, in which the main techniques and methods for spacecraft GNC are presented and deeply analyzed. Fault detection isolation and recovery methods, GNC veriﬁcation and validation tools, and on-board practical implementation are detailed with particular emphasis. Speciﬁcally: The Guidance chapter contains the different implementation philoso- phies of on-board and ground-based guidance, the formal discriminant be- tween AOCS and GNC systems; the guidance system design process, including two applicative cases of rendezvous guidance and attitude guid- ance; the most relevant guidance implementation best practices. The Navigation chapter describes the main navigation ﬁltering tech- niques, including sequential and batch ﬁlters; absolute orbit navigation, including the basics of GNSS, pulsars, ground-based orbit determination techniques; absolute attitude navigation; relative navigation; image process- ing techniques; the inﬂuence of navigation budgets on the overall GNC chain; the most relevant navigation implementation best practices. The Control chapter discusses the control design process, including both the design in the state space and in the frequency domain; an introduction to nonlinear control design; Proportional-Integral-Derivative control methods; Linear Quadratic Regulator methods; robust control fundamen- tals, including Model Predictive Control and Sliding Mode Control; the control budgets; the most relevant control implementation best practices. Introduction 7 The chapter about FDIR Development Approaches in Space Systems presents technical solutions and industrial processes used by the space engineers to design, develop, test, and operate health management systems, also known as Failure Detection, Isolation, and Recovery (FDIR) systems. The GNC Veriﬁcation and Validation chapter introduces the main indus- trial process to verify and validate a GNC system, including Model-in-the- Loop, Software-in-the-Loop, Processor-in-the-Loop, Hardware-in-the- Loop, In-Orbit testing activities. The On-board Implementation chapter presents a brief overview on the ﬁnal implementation of the GNC algorithms and functions in the on- board avionics’ modules, with the associated data interfaces; the main tech- nologies for modern processing devices, such as general-purpose Processors/ Microcontrollers, Digital Signal Processors, Graphical Processing Units, Field Programmable Gate Array, or speciﬁc ad-hoc electronic circuits. The last main Part 3 e AI and Modern Applications introduces the most advanced solutions for spacecraft GNC. The fundamentals of AI theory and some cutting-edge spacecraft GNC applications are described in this part. A strong focus to the space environment is imposed, and the main al- gorithms that can beneﬁt from AI or other modern computing techniques are considered, without an extensive, general treatment as a classical AI or computer science textbook. This part is different from a generic AI or com- puter science book to stress only the peculiar algorithms and aspects of mod- ern spacecraft GNC that are applicable in the space context. In particular: The Applicative GNC Cases and Examples chapter presents a set of appli- cative GNC examples and use cases covering the topics of GNC that are of relevance for practical and modern applications. It contains examples on AOCS design; orbital control systems; attitude control systems; relative GNC; on-board sensor processing; irregular solar system bodies ﬂy around; planetary landing. The Modern Spacecraft GNC chapter gives an overview on modern GNC techniques and methods, including an overview on AI techniques for space- craft, on the innovative methods for GNC FDIR, and on the emerging topic of CubeSats and nanosatellites. It contains an introduction to AI in space; AI techniques for spacecraft navigation; validation of AI-based sys- tems; reinforcement learning; AI use cases; AI on-board processors; innova- tive techniques for highly autonomous FDIR systems; small satellites and CubeSats GNC. 8 Vincenzo Pesce et al. Finally, an appendix section provides a summary of the fundamentals of mathematical and geometrical rules; dynamical systems theory; Automated Code Generation (ACG) or autocoding. How to use the book? This book is intended to cover the entire spacecraft GNC domain, with the most updated developments, trying not to leave any concept or application unexplored. However, the topics cannot be treated with the ﬁnest details of a specialized book. Thus, the book presents the main tools and methods to deal with the covered contents and support the discussion with several liter- ature references to further explore the topics. The reader should either have a sufﬁcient theoretical background on the matter, or it should deepen and review those concepts that are not completely clear after a ﬁrst reading of the book content. The book is designed and structured to support the practical work and the daily life of modern spacecraft GNC/AOCS engineers, aerospace engi- neers, avionic developers, and AIV/AIT technicians. Thus, it can be used as a handbook, without the need of reading it from the beginning to the end. The applicative examples and the modern GNC presented in Part 3 are sup- ported by the fundamentals of spacecraft GNC discussed in Part 2, which are developed starting from the basic tools introduced in Part 1. Hence, reading it bottom-up can be useful for an experienced GNC engineer who want to update his knowledge, while a student or a young professional is suggested to read it following the normal ﬂow. Most of the chapters in Part 1 and Part 2 are enriched with sections dedi- cated in summarizing the chapter’s aspects relevant for GNC applications or to list tips and best practices to design and practically implement the GNC functions into the spacecraft system. Similarly, some modeling guidelines are clearly outlined to better support the GNC design process. The chapters about FDIR systems, veriﬁcation and validation processes, and on-board implementation are self-contained, and they should be used to have a clear preliminary overview on these important concepts, often overlooked in classical textbooks about spacecraft GNC. Part 3 contains diverse and various applicative and modern concepts, spanning the entire applicative spectrum of spacecraft GNC. Thus, it is not uncommon that the different sections of this part belong to different domains and have a broad variety of terminology and theoretical concepts. Thus, Part 3 could be read considering each section as an autonomous block, performing the necessary links to the previous parts and to the appendices of the book. Introduction 9 What is not contained in this book? The book is intended to be a practical and useful support to the work and to the knowledge of spacecraft GNC/AOCS engineers, aerospace engineers, avionic developers, and AIV/AIT technicians. Thus, it is not designed to provide all the basic and theoretical concepts behind each of the covered contents. Moreover, the reader is expected to have a solid knowledge on mathematics, physics, dynamics, and basics of space systems. The description of orbital and attitude dynamics is constrained to the most relevant aspects useful for the GNC design. Consequently, few topics about orbit and attitude dynamics have been omitted, mainly because of length restrictions. All the landmarks and milestones of the GNC design and veriﬁcation are included, but the details are sometimes just hinted in or- der to avoid a lengthy and cumbersome discussion that would not ﬁt with the handbook purposes of this book. In all these cases, invitation for the reader to deepen those aspects on existing literature references is included. The book does not contain extensive discussion on theoretical aspects of spacecraft dynamics and environment modeling. Furthermore, it overlooks the theoretical details on sensors and actuators, focusing more on the prac- tical aspects about their integration in the GNC design (e.g., calibration, testing, and numerical modeling). In other words, in this book, environ- mental terms, dynamical equations, sensors and actuators are more intended as mathematical models, rather than as the physical principles they represent. The GNC description directly applies the methods to the spacecraft design; hence, no extensive discussion about general GNC methods is included. Moreover, mathematical derivations and proofs are limited to those cases where they are directly applicable in the design and veriﬁcation processes. The example and applicative cases are limited to those with interest in present and future mission scenario. Moreover, the focus is dedicated to modern applications that are somehow less common in classic literature about spacecraft GNC. Even in this case, proper references to classic litera- ture examples are included. The AI section only considers techniques and methodologies that are more consolidated in spacecraft GNC design. As already said, AI is speciﬁcally limited to spacecraft GNC; thus, an extensive, general treatment as a classical AI textbook is not contained in this book. Furthermore, given the close relation to research aspects, some details on the most innovative applications are given, highlighting their current devel- opment status and their applicative limitations. 10 Vincenzo Pesce et al. The list of covered applications is obviously not exhaustive, but contains those examples that are deemed to be more relevant for the modern chal- lenges faced, on a day-by-day basis, by the spacecraft GNC engineers. The editors apologize from now for any missing content the reader would have desired to ﬁnd in this book; the interested reader is invited to contact them to directly ask for speciﬁc suggestions on how to ﬁnd and deepen its knowledge about the missing topics. A brief historical review of classical spacecraft GNC Despite the concepts of GNC are intrinsic with the human move- ments across the globe, the true ancestor of spacecraft GNC is the ancient mariner, who had to explore the world by guiding, navigating, and control- ling the motion of an artiﬁcial object through a vast environment, still un- explored, without references and landmarks. Indeed, to master the art of driving a ship across the sea, humans outlined fundamental concepts, invented methods and tools that are nowadays still applicable to the whole ﬁeld of GNC. Three thousand years ago, Polynesians and Phoenicians mar- iners were capable to sail on the high seas, and ever since the humans have been developing celestial navigation, compass bearing, landmark ranging, route tracing, and so on. They also invented a variety of instruments and methods to accomplish these tasks. The ﬁrst magnetic compass used in nav- igation applications is dated back to the 11th century, the mariner’s astrolabe to the 14th century, the marine chronometer and the sextant to the 17th and 18th century. Similarly, the rhumb line or loxodrome navigation method was formulated and applied in the 16th century. Moreover, also the etymol- ogy of the word “navigation” belongs to the sea and to the mariners: it was ﬁrst used in the 1530s, from Latin “navigationem,” which derives from “navigatus” meaning “to sail, sail over, go by sea, steer a ship,” from “navis” (i.e., ship) and the root of “agere” (i.e., to drive). Note how at that time, and sometimes also in present days, the word navigation was encompassing the entire GNC deﬁnition. The direct evolution of maritime navigation (i.e., maritime GNC) was the aircraft GNC, which shared several common elements with his progen- itor. Indeed, airplanes move in vast regions following routes by means of navigation instruments and control systems, such as the pilot or the auto- pilot. In fact, as for the ships, the ﬁrst aircrafts were controlled by men, who read the information of on-board instruments (e.g., altimeter, compass, attitude indicator, etc.) to follow the path they computed before the take- Introduction 11 off. Namely, the ﬁrst aircraft GNC was human in the loop. A very similar evolution happened in space for spacecraft GNC. As obvious, spacecraft moving in space share most of the fundamental characteristics with the ships and airplanes traveling across the seas and in the skies, even though the orbital conditions are even more harsh and difﬁ- cult. The ﬁrst spacecraft were indeed only passively controlled: launched into ballistic trajectories (i.e., the natural orbits) and with passive rotational stabilization. The ﬁrst man-made object orbiting around the Earth was the Sputnik 1, launched by the Soviet Union on the fourth of October 1957. It was a simple polished metal sphere with a diameter of 58 cm, but it had no orbital and attitude control capabilities. The ﬁrst American satellite was the Explorer 1, launched on the ﬁrst of February 1958. It had not orbital control, and its rotational state was designed to spin the spacecraft around its elongated axis to achieve a passive attitude stabilization. However, soon after the release, the spacecraft entered in a ﬂat spin dynamics, an undesirable rota- tion about an axis perpendicular to the preferred axis. Later it was discovered that this was due to energy dissipation from ﬂexible structural elements, and this small accident motivated further developments of the theory of rigid body dynamics after nearly 200 years from the ﬁrst Eulerian formulation. The spacecraft dynamics was not completely understood yet to correctly develop a GNC system. The unmanned Luna-3 soviet space probe, which took pictures of the far side of the Moon in 1959, was the ﬁrst guided spacecraft, having a very basic attitude control system. It was spin-stabilized for most of its ﬂight, but its three-axis attitude control system was activated while taking photos. How- ever, the need to control the spacecraft motion increased with the advent of manned spacecraft and more complex orbital operations. The ﬁrst human in space was the Soviet cosmonaut Yuri Gagarin, launched with a Vostok 1 on the April 12, 1961. Despite he was a trained air force pilot, carefully selected to accomplish his task, the mission was designed to be automatically controlled or controlled from ground. In fact, the medical doctors were not sure how a human might react to space environment, and therefore it was decided to lock the pilot’s manual con- trols. This primitive spacecraft control system was only partially trusted by the spacecraft engineers themselves, and thus a code to unlock the controls was placed in an on-board envelope to be used in case of emergency. The code was “1-2-5,” and Gagarin was anyway told about it before launch. Anyhow, this sun-seeking attitude control system, inherited from the Luna-3 mission, was correctly activated at 06:51 UTC to orient the Vostok 12 Vincenzo Pesce et al. 1 for retroﬁre. The manual emergency back-up was not needed, and the cold nitrogen gas thruster systems were automatically controlled. Soon after Gagarin, the United States launched into orbit the astronaut Alan Shepard, on-board the Freedom 7 spacecraft, belonging to the project Mercury. The launch date was the ﬁfth of May 1961, and, after the launcher separation, the automated attitude control system (i.e., Automatic Stabiliza- tion Control System) damped out any residual tumbling motion. Then, it steered the spacecraft around 180 degrees, so the retrorockets would face forward, ready for ﬁring. Soon after that, Shepard began manually control- ling the spacecraft’s orientation. For redundancy purposes, the Mercury spacecraft’s manual and automatic attitude control systems used a different set of control jets, and they had individual fuel supplies. When Shepard piloted the spacecraft, moving the three-axis control stick, he proportionally opened the valves of the manual jets. The system could be selectively enabled on each axis, with the automatic control taking the lead on the non- enabled axes. Shepard gradually assumed manual control, one axis at a time. At ﬁrst, he took manual control of pitch, reorienting the spacecraft from its “orbit attitude” of 14 degrees nose-down pitch to the “retroﬁre attitude” of 34 degrees nose-down pitch, then returning to orbit attitude. He then took manual control of yaw along with pitch, yawing the spacecraft to the left and then to the right to bring it back in line. Finally, he assumed control of the roll axis as well, testing it and then restoring the spacecraft’s roll to normal. Once Shepard had taken control of all three axes, he found that the space- craft’s manual response was about the same as that of the Mercury simulator. Already then, the importance of setting up a proper design, veriﬁcation, and testing simulator was evident. The evolution curve of spacecraft design and on-orbit operations was extremely steep, and in a short time, the spacecraft were asked to accomplish complex tasks. The development of automated GNC systems was immedi- ately started, to both improve the spacecraft performance and to aid the as- tronauts to pilot the capsules. Anyway, most of the GNC capabilities were demanded to ground or to the astronauts on-board. It is interesting to note that until the late 1970s, the attitude estimation and navigation techniques actually remained in a very underdeveloped state. Similarly, most of the guidance solutions were computed on ground and telemetered to the spacecraft. The ﬁrst orbital rendezvous between two spacecraft was accomplished by the United States astronaut Wally Schirra on December 15, 1965. The Gemini 6 spacecraft was maneuvered within 30 cm of the target spacecraft: Introduction 13 the Gemini 7. The rendezvous was not ﬁnalized with docking, but the spacecraft maintained the proximity condition for more than 20 min. The astronaut later described the manual rendezvous with a remarkable comment: “Somebody said. when you come to within three miles (i.e., 5 km), you’ve rendezvoused. If anybody thinks they’ve pulled a rendezvous off at three miles, have fun! This is when we started doing our work. I don’t think rendezvous is over until you are stopped e completely stopped e with no relative motion between the two vehicles, at a range of approximately 120 feet (i.e., 37 m). That’s rendez- vous! Otherwise, it is the equivalent of a male walking down a busy main street with plenty of trafﬁc whizzing by and he spots a cute girl walking on the other side. He’s going ‘Hey wait’ but she’s gone. That’s a passing glance, not a rendezvous. Now if that same male can cut across all that trafﬁc and nibble on that girl’s ear, now that’s a rendezvous!” The necessity of completely automated GNC subsystem to perform even the most complex operations, such as rendezvous and docking, is therefore evident. In fact, the risks and the costs of sending astronauts in space or the extreme ground effort to support spacecraft operations make automatic spacecraft GNC fundamental for present space applications. Furthermore, modern spacecraft are required to accomplish these difﬁ- cult tasks (e.g., rendezvous and docking, planetary and minor celestial bodies landing, on-orbit servicing, etc.), at a distance from the Earth that makes ground support almost impossible in real time or dramatically expensive. Hence, nowadays, spacecraft are required to be autonomous and make cor- rect decisions, even in the case of unexpected circumstances. Indeed, we are currently in the epoch of autonomous and artiﬁcially intelligent spacecraft, exploring the space on Earth orbits and beyond, and the GNC system is crucial to guarantee this: it is the time of modern spacecraft GNC. GNC terminology The ﬁrst terminological deﬁnitions we shall introduce are those immediately related with the word GNC. According to the dictionary, the GNC is a branch of engineering dealing with the “design of systems to control the movement of vehicles.” In particular: Guidance is referring to the determination of the desired path (i.e., “tra- jectory”) from the vehicle’s current location to an assigned target. It also establishes the desired changes in velocity, rotation, and acceleration to follow that course. 14 Vincenzo Pesce et al. Navigation is referring to the determination, at a given instant of time, of the vehicle’s location, velocity, rotation, and angular rate (i.e., “state vector”). Control is referring to the manipulation of forces and torques, by means of actuators (i.e., steering device, thrusters, etc.), needed to follow the desired path while maintaining vehicle stability. For what concerns space engineering terminology, different names can be found to indicate similar subsystems, which are referred as GNC in this book. The deﬁnition of GNC can be casted into the set of functions in charge of targeted orbit and attitude computation, attitude and orbit deter- mination, attitude and orbit control. GNC is commonly used for the on- board segment, when the satellite position is controlled in closed loop, for instance, in case of rendezvous or formations ﬂying. In the most general terms, the GNC functions are: Attitude estimation, which is referred as attitude navigation or determi- nation in this book. Attitude guidance. Attitude control. Orbit control. Orbit estimation, which is referred as orbital navigation in this book. Acquisition and maintenance of a safe attitude state in emergency cases and return to nominal mission upon command. Real-time on-board orbital trajectory guidance and control. Real-time on-board relative position estimation and control, in case the mission requires it. AOCS is commonly used when the orbit guidance is not performed on board, which is the case for standard low Earth orbit (LEO), medium Earth orbit, and geostationary orbit missions. However, the GNC term can be also used for the whole function, distributed between on-board and ground sys- tems. The classical AOCSs considered here include the following functions: Attitude estimation, which is referred as attitude navigation or determi- nation in this book. Attitude guidance. Attitude control. Orbit control. Orbit estimation, which is referred as orbital navigation in this book. Acquisition and maintenance of a safe attitude in emergency cases and return to nominal mission upon command. Within the GNC domain, one can furtherly distinguish between AOCS and Attitude Determination Control System (ADCS). Many satellites do not Introduction 15 have any orbit control capabilities (e.g., without propulsion subsystem); thus, in some cases, the AOCS can be limited to the ADCS only, which features: Attitude estimation/determination, which is referred as attitude naviga- tion or determination in this book. Attitude guidance. Attitude control. Acquisition and maintenance of a safe attitude in emergency cases and return to nominal mission upon command. GNC architecture: from requirements to preliminary design The GNC is a complex subsystem that extensively involves hardware and software components. Indeed, as we will see throughout the book, the GNC system interfaces sensors (cfr. Chapter 6 e Sensors), on-board soft- ware (cfr. Part 2 and Part 3), and actuators (cfr. Chapter 7 e Actuators). Furthermore, many implemented algorithms or, at least, their design process require a very good knowledge of the orbital and the physical environment in which the spacecraft ﬂies. Let us systematically decompose the GNC subsystem in the so-called GNC architecture: Guidance. The term refers to the generation of desired future plans to fulﬁll the mission objectives. This entails the creation of reference trajec- tories, both translational and rotational, that the spacecraft needs to follow. The guidance module must deliver feasible trajectories based on the spacecraft capabilities; therefore, it must take into account the spacecraft system design, as well as the constraints and the feasibility of the mission. Given its higher level of abstraction, descending directly from the mission objectives, the guidance module has been reserved to ground control for many years, nevertheless on-board guidance has recently become prominent for innovative and daring missions. The guidance module generally needs the output of the navigation to deliver inputs to the control module. Such workﬂow shall not be intended as dogmatic, as many different system architectures can be deployed. Certainly, the guidance module needs to know the actual state of the system to adjust future trajectories to the current system status. A comprehensive description of the guidance module is presented in Chapter 8 e Guidance. 16 Vincenzo Pesce et al. Navigation. The navigation module interfaces with the sensors. It over- sees the sensing of the environment to deliver the best estimate of the current state of the spacecraft, both in terms of orbital and attitude state. The navigation entails different algorithms, which are highly dependent on the sensor suite implemented on-board. The main task of the navi- gation is to fuse measurements from different sensors to deliver the best possible estimate, also based on the environment knowledge. In general, the navigation output represents the input to the guidance and/or control module. A comprehensive description of the navigation module is presented in Chapter 9 e Navigation. Control. The control module interfaces with the actuators. It oversees the spacecraft reaction to the environment to follow the desired trajectory, based on the actual state of the spacecraft. It generally receives inputs from the guidance and navigation modules. A comprehensive descrip- tion of the control module is presented in Chapter 10 e Control. Sensors. The sensor suite is the ensemble of hardware in charge of sensing the environment to deliver a direct or indirect measurement of the space- craft state, both orbital and attitude one. Sensors must be characterized and calibrated because a proper modeling of their functioning is critical for the navigation algorithms to perform well. A comprehensive descrip- tion of sensors is presented in Chapter 6 e Sensors. Actuators. The actuator suite is the ensemble of hardware in charge of delivering either an external torque or thrust interacting with the envi- ronment. Also, actuators must be characterized and calibrated because a proper modeling of their functioning is critical for the GNC algorithms to perform well. A comprehensive description of actuators is presented in Chapter 7 e Actuators. Environment. The environment represents the ensemble of physical laws dominating the surrounding of the spacecraft. In other words, it is a mathematical representation of the natural forces and torques acting on the spacecraft. For a GNC engineer, the environment has a twofold role: on one hand, it represents a partially known entity that drives the actual system state, whose accurate modeling is critical to validate the developed algorithms; on the other hand, environmental modeling achieves different level of accuracy when designing the algorithms them- selves, depending on their complexity, computational burden, etc. In other words, the former is something we cannot do much about and the spacecraft is simply reacting to it, the latter is the engineering knowl- edge that needs to be traded-off in each application. A comprehensive Introduction 17 description of the space environment, the orbital and attitude dynamics is presented in Chapter 3 e The Space Environment, Chapter 4 e Orbital Dynamics, and Chapter 5 e Attitude Dynamics. A schematic of a generic GNC architecture is shown in Fig. 1.1. Another important block of the GNC system is represented by a set of management routines, which fall within the so-called FDIR system. Such system oversees the malfunctioning of the GNC system with the goal of detecting the anomaly, isolating it and to compute recovery action to main- tain mission operability in contingent situations. As thoroughly discussed in Chapter 11 e FDIR Development Approaches in Space Systems, the FDIR involves reasoning at system level, due to the fact that spacecraft anomalies may impact the GNC system bidirectionally. Indeed, the FDIR is directly interfaced with the Mission and Spacecraft Management (MSM) system, also known as Mission and Vehicle Management (MVM), which is in charge to oversee the overall behavior of the spacecraft and its subsystems, including the GNC one, in order to achieve the mission goals, managing the system phases and modes. Adding this to our scheme of Fig. 1.1, we obtain the scheme depicted in Fig. 1.2. The mission management is highly dependent on mission objectives, costs, and other collateral elements. Hence, ground control support is often Figure 1.1 GNC system architecture. Dotted lines are representative of alternative path of different potential system implementations. 18 Vincenzo Pesce et al. Figure 1.2 GNC-FDIR system architecture. Dotted lines are representative of alternative path of different potential system implementations. utilized in the FDIR and MSM loop, yielding semiautonomous systems that can handle only a subset of contingent situations. As mentioned, the reader is referred to Chapter 11 e FDIR Development Approaches in Space Systems for a comprehensive description of these management blocks. GNC subsystem design GNC subsystem design is an iterative process. Table 1.1 summarizes the typical steps in a GNC design process, with inputs and outputs that would be expected for each design step. The ﬁrst step of the GNC design process is the deﬁnition of guiding re- quirements based on mission goals, as shown Table 1.1. The GNC require- ments for the development of space programs are typically part of the Project Requirements Document, which is comprehensive of the entire mission. The levels of completeness and detail vary very much from project to project. Introduction 19 Table 1.1 GNC subsystem design steps. Design step Description Inputs Outputs 1 Subsystem requirements Mission GNC subsystem deﬁnition and requirements requirements derivationdsubsystem System criticalities requirements Subsystems constraints Mission Concept of Operations (ConOps) Mission timeline 2 Deﬁnition of GNC GNC subsystem List of different GNC modes requirements modes Subsystems constraints Mission ConOps Mission timeline 3 Environment and Spacecraft Station-keeping disturbance assessment geometry needs Operational orbit Disturbance forces Epoch and mission (i.e., internal and timeline external) Mission ConOps Disturbance torques (i.e., internal and external) 4 Sizing and selection of Spacecraft Preliminary GNC subsystem geometry deﬁnition of the hardware Operational orbit sensors suite Epoch and Preliminary mission timeline deﬁnition of Mission ConOps actuators suite Disturbances Preliminary Subsystem deﬁnition of constraints computational architecture (i.e., on-board software e OBSW e and on-board computer e OBC) (Continued) 20 Vincenzo Pesce et al. Table 1.1 GNC subsystem design steps.dcont’d Design step Description Inputs Outputs 5 Deﬁnition of GNC Sensors suite Algorithms for algorithm performance and GNC subsystem characterization Mode manager Actuators suite performance and characterization Subsystem performance requirements 6 Iterate from 1 Output from 1, 2, Reﬁned mission and 3, 4, 5 GNC subsystem requirements. This is very important for a designer that shall identify the right level of complexity and performance for the project. Let us state it as a golden design rule: A designer knows that he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away. For each mission, it is necessary to adapt the speciﬁed requirements through a complete tailoring process , which entails: To decide if a requirement is necessary, taking into account the speciﬁc functionalities required for the mission (cfr. golden design rule). For instance, if a mission requires an on-board navigation function, then the requirements dedicated to this function or to an on-board GNSS receiver are applicable. To adapt the numerical values of a requirement, considering the exact performances required for the mission. The designer must reason on the actual needs of the mission, without spending resources for unneces- sary performance level. To quantify the new hardware and software development necessary for the program, which is a key factor in adapting the veriﬁcation requirements. The types of GNC requirements can be divided into : Functional requirements. Operational requirements. Introduction 21 Performance requirements: these requirements are often referred to characterize the GNC system in terms of the following features: Performance errors and budgets. For a comprehensive description of these errors, please refer to Chapter 10 e Control e Control Budgets. Stability. It expresses the ability of a system submitted to bounded external disturbances to remain indeﬁnitely in a bounded domain around an equilibrium position or around an equilibrium trajectory. Stability margins. They are used to quantify maximum parameters ex- cursions preserving stability properties. The most frequent stability margins, deﬁned in classical control design (cfr. Chapter 10 e Con- trol), are the gain margin, the phase margin, the modulus margin, and, less frequently, the delay margin. Agility. It assesses the ability of a system to perform a maneuver in a given time interval, including the tranquilization phase. Transient response. It characterizes the ability of a system to reach the steady state with given maximum parameters. Common response metrics are the settling time or system overshoot. Robustness. It describes the ability of a controlled system to maintain some performance or stability characteristics in the presence of plant, sensors, actuators, and/or environmental uncertainties. Veriﬁcation requirements. Typically, as for other subsystems, the GNC requirements originate from mission requirements, expressed in various ways and directly linked to the ﬁnal objectives of the mission. It is interesting to report that international standard claims that, in some cases, it can be preferable to keep the perfor- mance requirements expressed at mission level and not at GNC level, in or- der to allow the best optimization of the system. An applicative use case showing the GNC design process from requirements to preliminary design is presented in Chapter 14 e Applicative GNC Cases and Examples. The GNC subsystem is a part of the whole spacecraft; thus, many re- quirements may also come from other spacecraft subsystems. The interfaces between subsystems are obviously critical to be assessed when dealing with system and subsystem design, especially GNC. An example of input/output relationship is given in Fig. 1.3. GNC modes Mission objectives and requirements often imply more than one mode of operating a spacecraft. Indeed, a contextual step to the requirement gener- ation is the identiﬁcation of the GNC modes. Often, the guiding 22 Vincenzo Pesce et al. Figure 1.3 Typical system and subsystem interfaces with GNC. requirements generally begin with a description of the control modes the GNC is expected to execute to meet those goals. This is because most of the requirements, functional, operational, and performance are dependent on the speciﬁc GNC mode involved. GNC modes shall be deﬁned by evaluating mission operations against: Flexibility. It is the capacity to adapt and solve more circumstances, without ambiguities, with simple and effective conﬁguration options. Autonomy. It is the capacity to be operative without the need of ground intervention. Redundancy. It is the capacity to be operative in case of the loss of some hardware components. Performance. It is the capacity to guarantee GNC functionalities with various control authority and computational performances. In principle, each GNC mode may rely on different sensors, actuators, navigation, guidance, and control functions. In particular, the GNC func- tions should be as independent and unique as possible. Typical GNC modes are reported in Table 1.2, and they are thoroughly discussed in Chapter 14 e Applicative GNC Cases and Examples. Introduction 23 Table 1.2 Typical GNC modes. GNC mode Tasks Characteristics Commissioning Commissioning of the GNC To be used before relevant system mission phases Sequential start-up of It should include a monitoring components of the system in order to be able to detect (autonomously or from ground) anomalies prior to the operative phases No particular performance requirement is imposed Refer to Chapter 12 e GNC Veriﬁcation and Validation Nominal It fulﬁlls the main mission Best performing hardware is objectives involved It may be comprehensive of Highest performance submodes, such as image requirements acquisition, communication pointing, proximity control Safe Detumble the satellite Reliable hardware is Power-saving employed Stable pointing, usually No performance requirement toward the Sun is imposed (i.e., also rough navigation or control are accepted) Must be autonomous Standby Power positive pointing It is typically autonomous Ground station pointing In general, the spacecraft is Particular pointing required by more operative with respect a set of subsystems (e.g., power to safe mode and thermal) Different GNC functions with Drag drift minimization (e.g., respect to Safe mode hold point) Orbit control It performs orbital maneuvers It can be split into inertial and relative maneuvers Propulsion subsystem is involved Parasitic torques coming from thrust misalignment have to be controlled Transfer It controls the attitude and It shares a lot with orbit orbital state during long control mode transfers (e.g., to get to GTO It may have additional system or interplanetary transfer) requirements during ballistic Interplanetary navigation arcs Special It fulﬁlls particular extended Various objectives of the mission 24 Vincenzo Pesce et al. System redundancy With respect to the mode’s characteristics, it is important to highlight the concept of redundancy. The harsh space environment yield degradation or failures of space missions. A typical requirement for many missions is the ability to survive and function even in the case components failures have occurred. Redundancy aims at implementing such requirement to pre- serve the full capabilities of the spacecraft. Redundancy can be split into cold, hot, and active : Cold redundancy design. The secondary hardware is not operative and nor- mally switched off until a failure on the primary component occurs. The advantage of such kind of redundancy is that the component does not require any power. Nevertheless, the latency of the system to react to the failure increases, as the secondary component needs to be turned on and, potentially, commissioned. Hot redundancy conﬁguration. All entities are powered on with only one operating. This allows a quick recovery of the functionality whenever a failure in the primary component occurs. Active redundancy conﬁguration. All the components are operative, and the system can continue to function without downtime or defects despite the loss of one or more entities. Finally, if redundancy is implemented at functional level (i.e., not on speciﬁc hardware), it is often referred as analytical redundancy. In an analytical redundancy conﬁguration, the function of a failed component is provided by using an entirely different component or ensemble of components, with a different set of GNC functions. Such strategy largely involves algo- rithm design and often requires higher computational cost. The redundancy of multiple GNC elements (e.g., architecture including sensors, on-board computers, actuators, etc.) can be implemented in mainly two different alternative conﬁgurations, namely in a block redundant or in a cross-strapped conﬁguration. Their difference is depicted in Fig. 1.4. Figure 1.4 Multiple elements redundancy conﬁguration. Dotted lines indicate redun- dant components in the nominal design. Introduction 25 Block redundant conﬁguration replicates two (or more) independent fully functional pipelines. Whenever one of the components (e.g., sensor 1, OBC, or actuator 2) fails, the entire pipeline is dismissed and the redun- dant is used, being it in cold, hot, or active redundancy. In a cross-strapped conﬁguration, each element is connected to both the nominal and the redundant successive element. Thus, the failure of one element in one pipe- line does not prevent the elements belonging to it to maintain their operativity. Both conﬁgurations are single-fault tolerant. Block redundant conﬁgu- ration has a simpler implementation, but it can withstand a second fault only if the failure occurs in the pipeline where the ﬁrst one occurred. It can be seen that the number of connections linearly scale with the number of redundant paths. Cross-strapped conﬁguration is certainly more robust at the cost of higher complexity, given the large number of additional connec- tions, potentially unused in nominal conditions. In this case, it is important to remark that the number of functional connections exponentially scale with the number of redundant paths. Each mission requires an accurate reliability analysis to deﬁne the proper redundancy strategy and conﬁguration. Moreover, throughout the genera- tion of the requirements, the deﬁnition of the modes, the selection of system redundancies and the preliminary design, the concept of trade-off is crucial. Several iterations, as detailed in Chapter 14 e Applicative GNC Cases and Examples, are required to converge to the ﬁnal GNC architecture. Mission phases The GNC system design, implementation, and operation follow the devel- opment of the standard mission phases. Table 1.3 reports an overview of the different phases of the life cycle of a typical space mission. Table 1.3 Mission life cycle. Mission analysis and Phase 0 identiﬁcation Phase A Feasibility Phase B Preliminary deﬁnition Phase C Detailed deﬁnition Phase D Qualiﬁcation and production Phase E Utilization Phase F Disposal 26 Vincenzo Pesce et al. During phase 0 and A of the mission design, prototypes of key GNC al- gorithms may be developed to demonstrate the feasibility of the intended approach. The GNC algorithms may be run in open loop as stand-alone functions, or they may be integrated in highly simpliﬁed simulators of the dynamics to ensure that the algorithms can sequentially run in discrete time. During the late phase A and in the early phase B (i.e., B1) of the mission design, a full simulator containing all the dynamical effects that are relevant for the GNC design may be implemented. However, this simulator still con- tains simpliﬁed models of the sensors and actuators. During phase A/B1, the architecture and the most important modes of the GNC functions are iden- tiﬁed. A preliminary implementation of the full GNC subsystem may be car- ried out and tested to demonstrate the feasibility of the GNC solution. Some efforts may be spent to ensure that all the functions meet the requirements on the computational load; that is to say, to demonstrate that the GNC func- tions can be executed within the available time. The technical requirements for the on-board software are deﬁned at the end of phase A. During the phases B and C, the GNC architecture and the functionalities of the GNC software are consolidated, and the engineering efforts shift to- ward veriﬁcation and validation of the software. Code analysis tools may be used to ensure that no prohibited operations (e.g., division by zero) can occur, and again to ensure that the GNC functions meet requirements on the computational load. During these phases, the software matures from prototypes to the actual ﬂight software. More attention is paid to the correct deﬁnition of interfaces and more detailed models of the real world, in partic- ular sensors and actuators, are included into the GNC simulator, as more in- formation from the hardware design of the spacecraft becomes available. During phase D, the ﬁnal version of the on-board software is integrated in the spacecraft computer for validation, veriﬁcation, and testing purposes. The whole system is manufactured and integrated to be ﬁnally qualiﬁed for the launch in space. Even the on-board software undergoes qualiﬁcation testing activities before launch. Finally, during phase E, the spacecraft and the GNC subsystem are utilized and operated by the operation engineers. The original software and GNC development team may be occasionally called upon to solve problems, and even patch software problems if required. Consider the anomalies An operational spacecraft shall be able to handle nonnominal conditions that may arise, endangering the correct operation of a given subsystem or the Introduction 27 overall mission. In fact, on-orbit maintenance is not yet a feasible and economically sustainable alternative for most of the space missions. For this reason, it is extremely important to design an FDIR subsystem to detect and successfully recover, in an autonomous or semiautonomous way, from faults. FDIR system development should be carried out in parallel with the mission design and it’s addressed since the very beginning of the GNC development. The deﬁnition of reliability, availability, and safety objectives is strongly dependent on the designed FDIR system. FDIR system conception and implementation for a spacecraft is an extremely complex task. This is particularly true because the analysis of spacecraft failures is not always straightforward. The cause of malfunctions could be one or more failed components, incorrect control actions, or external disturbances, which impact system operations. Usually, in order to identify the failure scenarios, reliability design analysis (i.e., risk analysis) techniques are used. In particular, Fault Tree Analysis (FTA) and Failure Mode Effects and Criticality Analysis (FMECA) are usually employed. FTA is a top-down deductive method where top-level failures are addressed and all the basic faults (i.e., failure causes), which can lead to such states, are identiﬁed. FTA helps to identify how the system or subsystem can fail and the best way to minimize the risk connected to a given failure. On the other hand, FMECA is an inductive bottom-up analysis, and it is used to compute the casual effects on the system of a given fault combination. It is primarily used to identify potential single-point failures. FMECA is usually applied for spacecraft risk assessment and the main process steps are [5,6]: Establish FMECA analysis approach. The purpose of this phase is to deﬁne the objectives of the analysis and the mission phases to be examined. Fail- ure modes and criticality levels are deﬁned. Procedures to be adopted and format of the ﬁnal FMECA worksheet are selected. System deﬁnition. Functional behavior, operational modes, and mission phases are identiﬁed. Construct functional block diagram. A functional block diagram of the system to be assessed is detailed. Blocks and outputs at the level of detail required for the analysis are identiﬁed. Identify failure modes and effects. All functional, hardware, software, and product single point failures are identiﬁed and eventually included into the critical items list. Critical items are those items which are reliability, mission, or safety critical. 28 Vincenzo Pesce et al. Failure mode effect. The failure effect for each mission phase and for the considered components is assessed. Failure detection method. Failure detection techniques are deﬁned for each mission phase. Telemetry and on-board fault management can be used to this purpose. Provide compensating provisions. Failure mode compensation methods are identiﬁed for each failure mode. This is usually carried out by the on- board autonomous fault management system (i.e., FDIR) or by the ground anomaly detection and resolution control system, which im- plements recovery plans and procedures. These methods can include fault tolerant systems, redundancy, workaround, and alternate modes of operations. Perform criticality analysis. Each failure mode is evaluated in terms of the worst potential consequences and a severity category is assigned. Documentation and reporting. Document the analysis and summarize the results and the problems that cannot be solved by the corrective actions. Recording. Record all critical items into a dedicated table as an input to the overall project critical item list. Once the FMECA documentation is produced, an assessment of the risk associated with each failure mode can be performed evaluating the following quantities: Severity number (SN): the severity of failure effects on the system. 1 e catastrophic. 2 e critical. 3 e major. 4 e minor or negligible. Probability number (PN): probability of occurrence of a failure mode. 1 e extremely unlikely. 2 e unlikely. 3 e likely. 4 e very likely. Detection number (DN): the probability of detection of a failure mode. 1 e very likely. 2 e likely. 3 e unlikely. 4 e extremely unlikely. Criticality number (CN): obtained as product of SN, PN, and DN (i.e., CN ¼ SN $PN $DNÞ It quantiﬁes the risk associated with a given fail- ure mode. Introduction 29 Mode management During the GNC design, the modes shall be deﬁned together with their transitions. Indeed, once the main modes at system and GNC subsystem level are identiﬁed, a mission manager has to be designed. The role of a mission management software is to provide commands to the GNC subsys- tem in order to adapt its modes and conﬁgurations to a speciﬁc mission phase. In general, an on-board mission manager shall perform four main tasks : Monitoring. Processing spacecraft state and status, checking for possible problems with the current plan. Given certain mission objective, the mission manager should be able to evaluate if the current state and status, propagated in time to the end of the mission phase, satisfy the given requirements. Diagnosis. Identifying problems with the current plan and conﬁguration and taking the action of replanning or reconﬁguration. This task is very similar to the FDIR objective even though mission manager diagnosis is limited to plan and conﬁguration problems. Planning. Creating a series of commands that achieve mission objectives. This is done at the beginning of the mission or after replanning. Execution. The plan is enabled by sending sequential commands to the Guidance and Control functions. This sequencing may be time- or event-triggered. A high-level schematic of a mode management system is reported in Fig. 1.5. Sometimes, to simplify the overall architecture, a plan is deﬁned be- forehand, and the mission manager tasks are reduced to monitoring and execution. This is a common practice for many spacecraft missions to reduce the overall mission complexity and shorten validation and veriﬁcation activities. Figure 1.5 Mode manager architecture. 30 Vincenzo Pesce et al. Mode transition and ﬁnite state machine During the design of a mode management system, particular attention must be paid to the deﬁnition of mode transitions. In general, a good practice while implementing GNC mode transitions is to accurately design them in order to avoid: Logical errors (e.g., an event triggering no state). Ambiguous states (e.g., an event triggering multiple states). Transition errors (e.g., an event triggering the wrong state). Unreachable states (e.g., states that cannot be activated by any event). Loop states (e.g., states that cannot be excited after their activation). A common solution to design GNC mode architecture and transitions is to use Finite State Machine (FSM) and visual programming. The combina- tion of these two tools allows for a formal, simple, and visual representation of the modes of architecture and eases the operator monitoring phase. An FSM is a mathematical model describing an event-triggered system, allow- ing to model transitions within a ﬁxed number of states. FSMs have the following properties: Can be in exactly one of a ﬁnite number of states at any given time. Change from one state to another (i.e., perform a transition) in response to some inputs. Are dynamics, discrete, ﬁnite. Can be represented as directed graph. FSM can be described in Speciﬁcation and Description Language, which can make these models executable for veriﬁcation, validation, and testing purposes. Two major types of FSM are acceptors and transducers. The main difference between these two categories of FSM is that an acceptor generates a binary output that indicates if the given input is accepted and rejected, while the transducers FSMs performs actions to generate the ex- pected outputs. Finally, an interpreter is needed to implement and execute the FSM. The simplicity of FSM models allows for a visual representation of states and modes transitions based on node-link diagrams (i.e., visual program- ming) using dataﬂow languages. A common software used for mode transitions and management is MATLAB/Simulink Stateﬂow tool. With this approach, each FSM can be treated as a single module and a dia- gram representing mode transitions through FSM can be graphically depicted, providing a very intuitive visual representation. Introduction 31 Automation, autonomy, and autonomicity During the design of mode management and, in general, of spacecraft oper- ations, different levels of autonomy can be identiﬁed. Even if we speak about autonomy while referring to a process executed without any human inter- vention, speciﬁc terms are deﬁned to indicate different facets of this concept : Automation. A sequence of commands is executed by software/hardware, replacing the corresponding manual process. No independent decision- making task is expected. In the case of automatic mode transitions, these steps are executed according to a given schedule (i.e., time-triggered), or after a task is completed, or after an event occurrence (i.e., event- triggered). Autonomy. Software and hardware components try to emulate the hu- man process rather than simply replacing it. In this case, human- independent decisions are expected. In the case of mode transitions, an internal logic is designed to command the mode switch based on the received states and status of FDIR and GNC subsystem. Autonomicity (or intelligent autonomy). This kind of systems is expected to be able to perform self-management rather than simply self-governance, as in the case of autonomy. In other words, autonomicity can be seen as a form of autonomy speciﬁcally designed to manage the system. As an example, the goal of a system may be to detect a given phenomenon using an on-board payload. The autonomy capability is to choose between different parameters to achieve this goal. However, the objective of ensuring that the system is fault-tolerant and continues to operate under fault conditions falls into the autonomicity domain rather than autonomy. Without autonomic capabilities, the spacecraft’s per- formance degrades, and the spacecraft may be unable to recover from faults. As discussed before, in the last years, the concept of autonomicity is gaining attention for spacecraft operation and design. Autonomic systems deﬁnition derives from the human Autonomic Nervous System that is the core of most nonconscious brain activities (e.g., breathing, reﬂex reactions, etc.). The idea is to have a self-managing system with the following objectives [11e16]: Self-conﬁguring. System’s ability to readjust itself automatically. Self-healing. System’s ability to recover after a fault occurs. Self-optimizing. System’s ability to measure its current performance and to improve it. Self-protecting. System’s ability to defend itself from external threats. 32 Vincenzo Pesce et al. On-board versus ground-based In general, a space mission consists of the ground segment and the space segment and controlling and operating a spacecraft is a task shared between the ground segment and the space segment, depending on the level of au- tonomy of the platform. Fig. 1.6 shows a ground-based control system. In this case, spacecraft data obtained from the sensors are sent to ground for processing, and commands are calculated under human supervision. These commands are uploaded to the spacecraft where the commands are stored and managed by the on-board computer. The on-board computer sends the commands to the actuators at the appropriate times. More computational power is available on-ground than on board a spacecraft. This means that the ground segment can use more complete models of the spacecraft dynamics and sensors, more sophisticated ﬁltering techniques to obtain a guidance solution, and more detailed dynamics models for computing maneuvers. Maneuvers can be computed on ground using optimization techniques that may be prohibitively expensive to imple- ment on-board or using techniques that require human supervision to ensure that the maneuvering solution is acceptable. In general, downloading the telemetry data requires regular ground station visibility, and the visibility Figure 1.6 Notional ground-based system. Introduction 33 windows determine the frequency with which the spacecraft orbit and atti- tude can be determined, and commands can be uploaded. The number of ground stations that are available and their overlap determine whether and how long continuous contact is possible, and how long a spacecraft needs to be able to survive between contacts. Needless to say, the more ground stations needed for the mission, the more expensive the operations become. Likewise, if the space segment needs to be monitored continuously by human operators, then the cost of operation is high. It is possible to design the overall mission in such a way that critical operations can count on continuous supervision, while during the less critical operations, the super- vision by human operators is reduced. Another important aspect is that downloading and processing the data and generating and uploading the commands can require a signiﬁcant amount of time. This is especially true for missions that take place in orbits that are further away than LEO. For example, a Mars Sample Return mission requires a higher degree of autonomy because the two-way light time can be as high as 48 min. In general, rendezvous missions may require autonomous abort capabilities for the close proximity operations as the re- action time available becomes too short for human operators to respond in time adequately. For example, if robotic proximity operations are conducted with a ground operator in the loop, then it may be necessary to download video data and upload thruster and robotic arm commands. This requires a high-bandwidth link, and if the operations are critical, it must be ensured that the operations can be completed within the ground visibility window. Fig. 1.7 shows an alternative control system in which more autonomy is placed in the space segment. A navigation function processes the data com- ing from the sensors, a guidance function provides the reference trajectory and the feed-forward forces and torques, and the control function provides feed-back forces and torques based on inputs from the navigation and the Figure 1.7 Notional on-board GNC system. 34 Vincenzo Pesce et al. guidance function. A mode manager is in charge of managing the overall behavior of the on-board GNC system. In recent years, microprocessors for space applications have become sub- stantially more powerful. However, on-board computational resources are still usually limited when compared to the resources available on-ground. This means that the algorithms for on-board applications tend to be less so- phisticated than the algorithms for on-ground applications. The advantage of having greater autonomy on-board is that it allows for less frequent commanding of the spacecraft. For example, this could enable missions that require ground personnel to be present at the mission opera- tions center only during working hours, which in turn would reduce the cost of operations. On the other hand, the increased level of autonomy also requires more time and effort to be spent on the development, veriﬁca- tion, and validation of the software, which increases the cost of the on-board software. In general, the reduction of the cost of operation is expected to be greater than the increased cost of the software development. A space system can also use a mixed approach. Some functions could be performed on-board while others are performed on-grou

Modern Spacecraft Guidance, Navigation, and Control PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue