Distributed GN&C Flight Software Simulation for Spacecraft Cluster Flight

Transcription

1 AAS Distributed GN&C Flight Software Simulation for Spacecraft Cluster Flight Shaun Stewart Lucas Ward Stacey Strand Emergent Space Technologies Inc. 37 th ANNUAL AAS GUIDANCE AND CONTROL CONFERENCE January 31 - February 5, 2014 Breckenridge, Colorado Sponsored by Rocky Mountain Section AAS Publications Office, P.O. Box San Diego, California 92198

2 AAS DISTRIBUTED GN&C FLIGHT SOFTWARE SIMULATION FOR SPACECRAFT CLUSTER FLIGHT Shaun M. Stewart, * Lucas Ward, Stacey Strand INTRODUCTION A spacecraft simulation environment was developed for testing distributed spacecraft flight software (FSW) designed for autonomous coordinated control of a spacecraft cluster. The Cluster Flight Application (CFA) FSW was developed by Emergent Space Technologies in support of the Defense Advanced Research Projects Agency (DARPA) System F6 Program. The CFA provides cluster flight guidance, navigation, and control (GN&C) functionality for controlling a cluster of spacecraft. This paper provides an overview of the Distributed Integrated Environment for CFA Analysis, Simulation, and Testing (DIECAST) used for CFA FSW development, verification and validation testing, and evaluation of CFA performance, reliability, and robustness. The Distributed Integrated Environment for CFA Analysis, Simulation, and Testing (DIECAST) enables the Cluster Flight Application (CFA) flight software (FSW) to be exercised in a range of on-orbit scenarios with a variable number of spacecraft, spacecraft properties, orbit elements, and relative cluster geometry. Spacecraft sensor and effector models were developed that enabled emulation of cooperative flight scenarios and inter-module communication within a spacecraft cluster. Sensor data and control commands are exchanged between the multi-spacecraft simulation and the CFA FSW. The resulting navigation and trajectory performance data is logged by the DIECAST simulation and used for performance assessment throughout the FSW development lifecycle. This simulation environment proved to be invaluable in the development process for the flight software. It enabled developers to run the CFA FSW in a desktop environment that provided a reasonable facsimile of the flight environment with a high-fidelity simulation that could be run faster than real-time. DIECAST is built upon the NASA Trick Simulation Environment (Trick), which provides a framework for building model-based simulations. 1,2 Trick includes an executive scheduler that allows the models and CFA FSW to be executed at specified rates throughout the simulation. Scenarios are configurable at run-time, with the intent to allow a single build of the simulation to support testing with a configurable number of spacecraft with unique geometry and initial conditions, beginning at any phase of flight. Development of spacecraft FSW capable of autonomous control of a generic spacecraft cluster requires performance verification on an enormous range of operational scenarios. Consequently, the CFA FSW is required to support a variable number of * CFA Simulation Lead, Emergent Space Technologies, Inc., 6411 Ivy Lane, Ste. 303, Greenbelt, MD CFA Simulation Team, Emergent Space Technologies, Inc., 6411 Ivy Lane, Ste. 303, Greenbelt, MD CFA V&V Lead, Emergent Space Technologies, Inc., 6411 Ivy Lane, Ste. 303, Greenbelt, MD

3 spacecraft in a variety of cluster configuration and orbits. In addition, the FSW execution is distributed among the members of the cluster, which creates added complexity with potential changes in the deployment of the FSW components and spacecraft interfaces during a mission. The DIECAST simulation simplifies the problem of FSW verification by providing a common FSW interface for embedded and hardware-in-the-loop (HWIL) testing, and allowing all scenarios to be evaluated with run-time inputs to a single build of the simulation. Figure 1 shows how the CFA FSW is embedded within the DIECAST simulation. The CFA FSW applications are compiled into libraries and wrapped with a Trick adaptor that enables the services to be run and scheduled by the Trick simulation executive. Embedding the FSW within the simulation in this manner allows the CFA functionality to be exercised in a controlled and repeatable fashion. A key benefit of this approach is that it enables incremental progression from prototype FSW development to FSW testing with a real-time operating system (RTOS) and HWIL. Figure 2 shows how the same simulation architecture, models, and interfaces are used when testing with the FSW running on a RTOS. Custom adaptors were developed for each environment allowing the same core FSW to be exercised in DIECAST and the flight runtime environment. This paper provides an overview of the design and implementation of the DIECAST simulation architecture used for development of the Emergent CFA flight software for the DARPA System F6 project. The details of each component of the DIECAST architecture are discussed in more detail in the following sections. Figure 1. DIECAST embedded FSW architecture. 2

4 Figure 2. Simulation architecture for RTOS FSW testing. CLUSTER FLIGHT APPLICATION OVERVIEW The Emergent CFA FSW is designed to be an enabling technology for spacecraft cluster flight missions. It would provide a generic capability for dissimilar spacecraft to operate collaboratively in close proximity in low Earth orbit. It would provide navigation and guidance services for the cluster, autonomous collision prediction, and automatic failure detection and recovery for the primary system applications. The CFA works to minimize overall propellant usage and nominally ensures near-zero probability of collision. This capability would enable a spacecraft cluster to conduct extended missions with limited command and control interaction from the ground and could thereby significantly reduce the cost of operating a spacecraft cluster on-orbit. The CFA is designed to be flexible and configurable, a capability that is realized in the convergence of a number of features. Specifically, the CFA scales seamlessly with increasing cluster size and supports the ability to add and remove satellites to/from the cluster during a mission. It is robust to changes in network configuration, data latency, and communication dropouts to one or more nodes in the cluster. It is intended to support application failover and/or specific service relocation between spacecraft which is especially beneficial for shifting processor intensive services to more capable nodes when required. The CFA is platform agnostic, with standardized interfaces and device abstraction that enables dissimilar spacecraft to connect and collaborate in a common cluster network. The CFA services include: Cluster Flight Manager (CFM), Orbit Maintenance Service (OMS), Maneuver Planning Service (MPS), Navigation Service (NAV), Module Maneuver Service (MMS), and Module Proxy (MPx). See References 3, 4 and 5 for an in-depth discussion of the CFA FSW architecture and services. Prototype CFA Algorithm Development For prototype algorithm development, Emergent leveraged an emerging MATLAB capability to auto-code MATLAB functions into C and C++. 6 This approach to software development enabled algorithm designers to rapidly implement prototype GN&C algorithms and leverage MATLAB plotting and data evaluation tools. The MATLAB algorithms are peer-reviewed by the Principle Investigator, Software Architect, and CFA software leads for design and functionality. In addition, a static code analysis tool is used to evaluate the resulting autocoded C and C++ 3

5 code. This approach has shown to also have benefits later in the FSW validation phase, as developers can go back to the original prototyping arena to address and fix algorithm issues without major downstream implications as long as the external component interfaces are maintained. The core functionality for most applications consist of some mix of auto-coded C-code and handwritten C++ classes. CFA services that use auto-generated code libraries include MPS, OMS, and NAV. CFA FSW Encapsulation / Adaptor Abstraction Ultimately, the core software for each CFA service is compiled into separate libraries that are integrated into the run-time environment through an adaptor. The adaptor is a C++ class which provides data translation between the messaging databus and the FSW applications. An abstract adaptor class is developed for each service that defines the types and methods that are required to instantiate an instance of the CFA service adaptor. For messages incoming to CFA, the adaptor translates incoming data into the appropriate CFA data type and calls the appropriate servicelevel entry point methods. For outgoing messages, the adaptor translates the CFA data type into an OS-specific data type and publishes the message. Because the adaptor must contain platform-specific functionality, the abstract adaptor class defines the required data interface for each service and is a template for the development of implementation-specific adaptors for the target runtime environment. This approach enables the application to be developed in a platform agnostic manner. Data interfaces are clearly defined in the abstract adaptor class, and platform-specific capabilities such as file I/O and data storage are required but not implemented until the adaptor is developed for a particular platform. DIECAST SIMULATION The DIECAST simulation is designed to exercise the CFA FSW and is not an attempt to emulate a flight runtime environment. DIECAST is designed to integrate CFS FSW into a common environment where CFA functionality can be exercised and tested in a controlled and repeatable fashion. The extent of configurability of the DIECAST simulation is due in large part to features added to the latest version of Trick, Trick13. For instance, the input file is wholly written in Python and grants access to many simulation C/C++ calls, and variables are available in the input file. These features are used extensively in setting up different scenarios for testing CFA. FSW Integration As mentioned, the auto-generated C code for a particular CFA service can contain function names that may conflict with the generated code from another service. This is problematic when creating a single Trick simulation executable that contains the entirety of the CFA FSW, as the linking phase of building fails with multiple reference errors for those functions. To avoid such collisions, applications that depend on a C library generated from MATLAB code are integrated into their own Trick simulation executables, described in Table 1. The four simulations that make up the DIECAST simulation are run by taking advantage of Trick s built-in master/slave capability. The SIM_embedded_cfa_fsw acts as the master and will start any slave simulations it is instructed to via the Trick input file. Implementations of each CFA service adaptor are required to integrate a service with the operating system and target platform. For integration with the DIECAST simulation, Trick-specific implementations of each adaptor were created to provide a data interface between the FSW applications and the DIECAST cross-application messaging system. 4

6 Simulation SIM_embedded_cfa_fsw SIM_mps_fsw SIM_cfm_oms_fsw SIM_nav_fsw Table 1. DIECAST simulation executables. Purpose Runs the environment, instances of cluster modules, module dynamics, FSW Module Maneuver Service (MMS), module proxy stand-in, graphics (if desired) Links in the MPS_private library, as well as the MATLAB generated library. Links in the CFM_private, OMS_private, and the MATLAB generated OMS libraries. Links in the NavFilter_private, NavManger, and the MATLAB generated NAV libraries. Scenario Configuration The range of operational configurations that CFA is designed to accommodate (multiple disparate cluster modules, varying orbits, differing cluster configurations, etc.) levies a requirement that the DIECAST simulation be able to support flexible testing. This is primarily supported through run-time configuration via the simulation input file. The Trick input file can be used to call external Python scripts and ensure simulation and FSW input files are configured with consistent assumptions. A Python script is used to set links to FSW configuration files based on which scenario is being run. Trick enables the user to configure C/C++ simulation model variables from the Python input file. This is utilized extensively to set data items such as the date of the simulation, set cluster module initial conditions, configure modules (mass, mass properties, engine properties, etc.), and to create a timeline for injecting commands into the CFA FSW. Currently, the capability exists for running simulations with cluster sizes of 2, 3, or 4 spacecraft. Simulation Models Mission Manager. A spacecraft manager application was developed that emulates the behavior of spacecraft FSW responsible for receiving CFA commands and executing maneuvers on the vehicle. This functionality is outside the scope of the CFA as it is highly bus-specific. However, a simple functionality for verifying, queuing, and executing maneuver commands from the CFA was required for testing CFA GN&C performance within the emulated testing environment. Orbital Dynamics. In addition to being built on the Trick Simulation Environment, DIECAST also utilizes Johnson Space Center s Engineering Orbital Dynamics (JEOD) Package for orbital dynamics models. 7 JEOD is designed for use with Trick and contains a set of numerical mathematical models for solving a system of 6DOF Newtonian force and torque equations for one or more spacecraft. These models have over 15 years of heritage for modeling spacecraft flight in and about the ISS. These models are comprised of: (1) Environment models representing the gravitational and non-gravitational forces and torques acting on a vehicle, (2) dynamics models for processing and numerically integrating the equations of motion, (3) interaction models representing interaction with the environment, and (4) a set of mathematical and orbital dynamics utilities. For completeness, they are listed in the Table 2 below. 5

7 Table 2. JEOD orbital dynamics models. Comm-based Radio Ranging. Radio range measurements are made between all spacecraft which are determined to be within communications range. The ModuleIMD (Inter-Module Distance) class is used to compute the true range and range-rates between all spacecraft pairs in the cluster. The CommRange model was configured to emulate performance of the Ka-band space cross-link radio selected for use on the DARPA System F6 project. The model injects a ±1 meter initial bias and 6 meter uniform noise in computation of the radio range measurement. The model does not account for the locations of the antennas with respect to the spacecraft structure. It is assumed that the radios adjust for the offset between the radio antenna location and the geometric center of the spacecraft during generation of the measurement, and that this functionality is outside the scope of the CFA FSW. Propulsion. There are two primary components of the spacecraft propulsion model: the engine and the propellant. The engine model is configurable such that a user, via the input file, can select whether the engine will perform impulsive or finite burns. In each case, the engine is commanded from the CFA flight software with a data packet that contains a centroid time a delta-v (dv) magnitude, and a unit vector that represents the desired direction that the dv should be applied in an inertial reference frame. The finite burn engine model leverages the reaction control system (RCS) model from JSC s Common Model Library (CML). 8 The model calculates forces and torques due to RCS jets and depletes propellant based on usage. The RCS model is configurable with ramp-up and rampdown times and a maximum dv performance to produce a trapezoidal burn model. The output of the RCS model are force and torque vectors which are then integrated into the spacecraft dynamics after being passed to Trick routines that collect external forces and torques for integration. The JEOD dynamics manages the application of these forces and torques to the spacecraft. Maneuver execution errors can be applied to the maneuver timing, magnitude, or direction. These are configurable options that can be enabled or disabled at runtime. Global Positioning System. The Global Positioning System (GPS) models used in the DIECAST simulation are based on existing models from CML but are significantly upgraded for the purposes of CFA development for the DARPA System F6 project. The upgraded model consists of five C++ classes for modeling the GPS constellation, the GPS ephemeris, the GPS antenna, the GPS receiver, and the GPS PVT navigation filter. The GPS constellation model is used to model the position and velocities of all the satellites in the GPS constellation. The transmitted L1 radio-frequency signal ( MHz) for each GPS satellite is modeled as well as the GPS constellation ephemeris and almanac data packets. The 6

8 GPS constellation models the orbits of a 32-satellite GPS constellation and provides the true position and velocity for each of the satellites at a given epoch. This, in turn, is used to support computation of the true range and range-rate to a GPS receiver antenna throughout the simulation. This truth data is also used as the basis for the GPS ephemeris and almanac data packets that are transmitted by the GPS constellation. The errors for all the parameters in these packets are estimated and used to corrupt the truth data in such a way as to closely emulate the actual nature of the GPS navigation packet. The GPS receiver model is a high-fidelity GPS model that models the instantaneous range and range-rate to all satellites in the GPS constellation and computes the individual error sources for each measurement type. The GPSReceiver class models the GPS signals, measurements, and receiver post-processed navigation outputs. The GPS functions within the class have been separated into three groups of code: (1) sensor initialization functions, (2) GPS signal acquisition, tracking, and raw measurement modeling functions, and (3) GPS measurement filtering functions. For the DIECAST simulation, a single 24-channel dual-rf GPS receiver is modeled that assumes the availability of two GPS antennas, which are oriented such that nearly 360 degree visibility is achievable. The model produces pseudorange estimates for all GPS satellites that are in view and can be tracked. In addition, a least squares filter is run onboard to produce point position, velocity, and time (PVT) estimates at 1Hz. EDGE Graphical Situation Awareness Tool EDGE is a three-dimensional (3D) graphics plug-in developed by NASA JSC for use with the Trick Simulation Environment. 9 EDGE allows drop-in integration with the NASA Trick Simulation Environment and provides a fusion of 3D graphics and simulation outputs. The EDGE tool uses data from the Trick simulation to help the user to visualize spacecraft trajectories and 6DOF spacecraft motion in orbit. The availability of a situational awareness tool that supports multiple visualization frames and simultaneous camera views is a tremendous benefit when trying to evaluate group behavior of a spacecraft cluster. The figure below shows an example of a cluster flight scene depicted by the EDGE graphics tool. PATH TO FLIGHT SOFTWARE Figure 3. EDGE Graphical Situational Awareness Tool. The development and testing undertaken to date has been conducted on the platform agnostic run-time environment provided by Trick and DIECAST. The benefits of this environment result from the inherent nature in which processes are executed; specifically, the ability to lock down the input conditions and reproduce bit-for-bit the results of a prior simulation run is invaluable during FSW development and testing. FSW embedded within the simulation environment also provides built-in data logging and plotting capability that enables evaluation of FSW variables 7

9 without requiring the FSW to be muddied with non-flight logging code. The forward path for maturing the CFA FSW involves transition to a flight platform and distributed operating system. Run-Time Integration NASA has developed an open source run-time executive called the Core Flight Executive (cfe) which has space flight heritage on a variety of missions. 10 The cfe also has a host of Platform Specific Packages (PSP) and Operating System Abstraction Layers (OSAL) for a variety of platforms. NASA has also developed a Trick-cFE target capability that enables unmodified cfe applications (i.e. the core FSW and flight cfe adaptor) to be run faster than real-time in Trick. For these reasons, the cfe is being considered as an ideal next step in maturing the CFA FSW for flight integration and testing. The FSW encapsulation approach enables ease of integration with the cfe run-time architecture. The Trick adaptor can be used as a template for development of the cfe adaptor for hosting and running the CFA FSW within the cfe runtime environment. By being able to test and run the same software in incrementally more realistic flight environments, this enables the developers to quickly develop the core software functionality early on, and provides capability for crossvalidating the FSW in both the development and flight platforms as the software is matured and ported for flight. The figure below shows the incremental phase of FSW development that enables core FSW components to be re-used as the project progresses. During the early phases, Phase 1 and Phase 2, the Trick simulation executive, dynamics and bus models are compiled with the FSW embedded with the simulation executable. In this mode, the Trick simulation is effectively acting as the run-time executive, responsible for controlling how to the FSW processes are executed, allowing for test runs to be conducted in a repeatable faster-than real-time manner. In the later phases, the FSW is compiled as a stand-alone application, running on the development platform in Phase 3 and on the flight computer in Phase 4. During this phase of testing, the simulation is running in parallel with sensor data and effector commands being exchanged over a realtime TCP socket connection with the FSW application. VERIFICATION AND VALIDATION Figure 4. Incremental flight software integration. Development of the CFA FSW was largely driven by use cases, as opposed to traditional shall statements, to define CFA system level behavior and responses. Areas of functionality 8

10 were broken out into nominal and off-nominal categories in the use case model which define the required functionality and high-level architecture. For each use case category, multiple use cases were generated to further define behavior including basic, alternate, and exception flows, as applicable. These system-level use cases were the basis for not only developing the software, but for defining verification and validation test scenarios. System test scenarios were developed to exercise as many flows as possible through the software functionality, with one to many relationships (use cases to test scenarios). For each test scenario, a unique input file was created to exercise the functionality of the use case flows, including environment set-up, ground commands to CFA, and logging data to verify the system responses. As CFA builds were released for testing, tags were created to freeze the CFA FSW and DIECAST build environments, to ensure stability and repeatability of behavior. Test cases were executed against the tags and the recorded data was analyzed to determine the CFA system behavior. Any discrepancies in behavior between the use cases and the test results were entered as defects in the defect tracking tool. Following testing cycle completion, all test inputs files, data setup, and results were committed to configuration managed repositories for regression testing and comparison against future version releases of the software. To track results of each testing cycle, a Verification Traceability Matrix (VTM) was created to map use cases to test cases relationships and indicate PASS/FAIL status. RESULTS Three-Module Ingress/Egress Scenario Below are results from a Nominal Operations testing scenario with a three-module cluster. Each spacecraft is conducting navigation activities processing GPS PVT, GPS pseudorange, and relative range data. Figures 5 and 6 show trajectories for the scenario over a period of approximately 18 orbits. Initially modules one and two are in passively safe parking orbits approximately 60 km downtrack of the target reference orbit. Module three is conducting station-keeping operations while modules one and two conduct ingress maneuvers to achieve their target orbit location in the spacecraft cluster. Figure 5. Three-module ingress scenario trajectories (2D in-track vs. downtrack view). 9

11 Figure 6. Three-module ingress scenario trajectories (3D view). Figure 7. Min/max inter-module distance for a three-module ingress scenario. The ingressing modules execute a maneuver plan over three orbits and then begin stationkeeping after successfully reaching their assigned slot in the cluster. All three modules conduct station-keeping operations for six orbits, until module one is issued a command to egress the cluster. Module one executes an egress maneuver plan over the following three orbits until finally is parked outside 10 km uptrack of the cluster. Figure 7 shows the minimum and maximum intermodule distances between any two modules in the cluster during the18-orbit scenario. This chart shows that the modules have stable relative geometries throughout the scenario. The spacecraft are initially holding at the 60 km parking orbit distance, never exceed the 1 km minimum intermodule distance constraint while conducting station keeping operations in formation, and finally holding a safe 10 km separation from module one after its cluster egress. 10

12 Four-Module Cluster Reconfiguration Scenario Below are results from a Cluster Reconfiguration scenario with a four-module cluster. Each spacecraft is conducting navigation and station-keeping activities over a 24-orbit period. After two orbits of stable station-keeping, modules two, three, and four are issued commands to shift their orbits to a larger diameter relative orbit. Over the next seven orbits, all three modules transition to their new orbit slot effectively increasing their minimum distance to any other module from 1.7 to 2.3 km. Figure 8 shows that the cluster is successfully reconfigured after seven orbits (at t=60,000 sec) and subsequently maintains stable relative orbit geometry for the remaining time, approximately 12 orbits, until completion of the test scenario. CONCLUSION Figure 8. Four-module reconfiguration scenario. There were numerous lessons learned during development of the CFA FSW and the DIECAST simulation and testing environment. Significant time, effort, and money was saved by leveraging the Trick, JEOD, CML, and EDGE software packages that are developed and maintained by NASA. These packages are freely available for use on government projects. They are being actively maintained and improved, and are designed to integrate together. The JEOD tutorial provides a good template for building a Trick simulation from scratch. The Python input file capabilities provided by Trick13 enable code-like functionality and scripts to be implemented at run-time without requiring a rebuild of the software. This enabled significant time savings in being able to test of run a tag of simulation and FSW while exercising numerous test cases and scenarios with a single build. The ability to replicate testing results via a repeatable simulation environment is a crucial capability in isolating and resolving FSW issues. The availability of a stable development and testing platform can save enormous time and effort when compared to an environment which can only intermittently capture or reproduce known issues. FSW encapsulation and incremental testing also saved significant time and effort. Enabling algorithm developers to develop complex algorithms in a versatile tool such as MATLAB significantly reduces the effort to identify and fix algorithm issues identified late in FSW development. The abstract adaptor approach also enables FSW to be exercised in multiple platforms, enabling core functionality to be exercised in early testing while platform issues are tackled only after the platform is available for HWIL testing. 11

13 ACKNOWLEDGMENTS The authors would like to thank NASA JSC (EG and ER), NASA Goddard, and METECS Inc. for the excellent support provided in integrating the aforementioned government simulation and testing tools for the DARPA System F6 project. Developing and testing the DIECAST simulation and CFA FSW would have been immensely more challenging without their efforts and support. REFERENCES 1 Paddock, E., Lin A., Vetter K., Crues E., Trick : A Simulation Development Toolkit." AIAA Modeling and Simulation Technologies Conference and Exhibit. Austin TX, Aug Innovative Simulation Toolkit for Constructing Simulations. NASA Technology Transfer and Commercialization Office. < 3 O Connor, B., Brown A., Gordon K., Schmidt J., de la Torre R., A Service-based Architecture for Automated Guidance, Navigation and Control Flight Software." 2013 Workshop on Spacecraft Flight Software. Pasadena CA, Dec Schmidt, J. and M. Phillips, A Distributed, Redundant Navigation and Fault Detection System for DARPA System F6." AIAA Guidance, Navigation, and Control and Co-located Conferences and AIAA Infotech@Aerospace Boston, MA, Aug Hur-Diaz, S., et al, "Computing Collision Probability Using Linear Covariance and Unscented Transforms," AIAA Guidance, Navigation, and Control and Co-located Conferences and AIAA Infotech@Aerospace 2013, Boston, MA, Aug MATLAB Coder. The Mathworks Inc. < 7 JEOD Determines Dynamic State of Spacecrafts. NASA Technology Transfer and Commercialization Office. < 8 Acevedo, A., Arnold, J., Othon, W., Berndt, J., ANTARES: Spacecraft Simulation for Multiple User Communities and Facilities." AIAA Modeling and Simulation Technologies Conference and Exhibit. Hilton Head SC, Aug Enhanced Graphics Tools for Advanced 3D Simulations. NASA Technology Transfer and Commercialization Office. < 10 Core Flight Executive (cfe). Code.NASA. < code.nasa.gov/project/core-flight-executive-cfe> The views expressed are those of the author and do not reflect the official policy or position of the Department of Defense or the U.S. Government. 12